From nobody Tue Jun 5 05:33:46 2018 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 4957D131006 for ; Tue, 5 Jun 2018 05:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 qXPnyO0QzEHj for ; Tue, 5 Jun 2018 05:33:40 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.38]) (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 5084C131007 for ; Tue, 5 Jun 2018 05:33:40 -0700 (PDT) Received: from 1fQB9e-0004vl-TL by out11d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fQB9e-0004xB-UG for ace@ietf.org; Tue, 05 Jun 2018 05:33:38 -0700 Received: by emcmailer; Tue, 05 Jun 2018 05:33:38 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fQB9e-0004vl-TL for ace@ietf.org; Tue, 05 Jun 2018 05:33:38 -0700 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.1466.3; Tue, 5 Jun 2018 14:33:37 +0200 To: "ace@ietf.org" From: Ludwig Seitz Message-ID: Date: Tue, 5 Jun 2018 14:33:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: [Ace] Results of the ACE interop test 2018-05-30 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 12:33:44 -0000 Hello ACE, we held an interop on the implementations of draft-ietf-ace-oauth-authz and draft-ietf-ace-dtls-authorize on May 30th. We had 3 participants and some attendees that just listened in. The implementations we tested were: * ACE-Java by Ludwig Seitz (me), RISE SICS https://bitbucket.org/lseitz/ace-java * A client by SEI lab of CMU based on some of the ACE-Java code * Jim Schaad's C# implementation https://github.com/jimsch/Oauth-Authz (Jim is that correct?) The tests we planned to execute can be found here: https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt The results can be found here: https://github.com/ace-wg/ace-oauth/blob/master/AceInterop2018-05-30.xls Note that I have heard of several more implementations, which couldn't make it for that first interop, namely: - A constrained RS implementation by SEI lab of CMU - A constrained (client/RS?) implementation by TZI, University of Bremen - A commercial implementation by ARM I think it would be nice for the group if the authors of the libraries above could say a quick word about the status of their respective implementations. Kind regards, Ludwig Seitz -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue Jun 5 07:55:22 2018 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 484181310C6; Tue, 5 Jun 2018 07:55:15 -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 BEBRiNDCTEh0; Tue, 5 Jun 2018 07:55:13 -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 69AF61310C3; Tue, 5 Jun 2018 07:55:13 -0700 (PDT) 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 w55EtA4B005209; Tue, 5 Jun 2018 16:55:10 +0200 (CEST) Received: from client-0081.vpn.uni-bremen.de (client-0081.vpn.uni-bremen.de [134.102.107.81]) (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 410Zbf0c0JzDXBP; Tue, 5 Jun 2018 16:55:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <152820873549.19149.17710091826447318076.idtracker@ietfa.amsl.com> Date: Tue, 5 Jun 2018 16:55:10 +0200 X-Mao-Original-Outgoing-Id: 549903308.400243-138949a414a5d0be9b20af473de829c9 Content-Transfer-Encoding: quoted-printable Message-Id: <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> References: <152820873549.19149.17710091826447318076.idtracker@ietfa.amsl.com> To: core , ace X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Ace] New Version of draft-fossati-core-multipart-ct-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 14:55:16 -0000 In https://github.com/SanKumar2015/EST-coaps/pull/50, Klaus has proposed = to introduce a media type for efficiently combining multiple = representations, along with the Content-Format numbers of their media = types, into a single representation. I believe we have needed such a media type in other places, so I have = extracted the content of that PR, and revved = draft-fossati-core-multipart-ct (of 2013 vintage) with that. This would = give us a media type multipart/core for general use. (Thanks are due to = Klaus and Thomas for helping me with this little exercise.) CoAP-EST is due to be finished very soon, and extracting this media type = from the CoAP-EST draft should only be done if we can avoid creating a = hazard for CoAP-EST to be delayed by this. I don=E2=80=99t see such a hazard unless we are having fundamental = problems with the approach (but do accept its limited use in the = CoAP-EST space). So it would be useful to get some quick reactions on whether we can go = ahead with this. If you don=E2=80=99t want to read the draft right now, its technical = content is: multipart-core =3D [* multipart-part] multipart-part =3D (type: uint .size 2, part: bytes / null) (Where =E2=80=9Ctype=E2=80=9D is the content-format identifier.) Gr=C3=BC=C3=9Fe, Carsten > Name: draft-fossati-core-multipart-ct > Revision: 04 > Title: Multipart Content-Format for CoAP > Document date: 2018-06-05 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-fossati-core-multipart-ct-04.tx= t > Status: = https://datatracker.ietf.org/doc/draft-fossati-core-multipart-ct/ > Htmlized: = https://tools.ietf.org/html/draft-fossati-core-multipart-ct-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-fossati-core-multipart-ct > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-fossati-core-multipart-ct-04 >=20 > Abstract: > This memo defines multipart/core, an application-independent media- > type that can be used to combine (even recursively) several = different > media types into a single CoAP message-body with minimal framing > overhead, along with a CoAP Content-Format identifier. From nobody Tue Jun 5 08:25:47 2018 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 64DB51310F3; Tue, 5 Jun 2018 08:25:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YGQ8rOem7Q7M; Tue, 5 Jun 2018 08:25:42 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE3E1310F2; Tue, 5 Jun 2018 08:25:42 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 705FB181D0286; Tue, 5 Jun 2018 15:25:41 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:2:41:72:152:355:379:582:599:800:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1535:1575:1588:1589:1592:1594:1606:1730:1776:1792:2068:2069:2198:2199:2525:2528:2559:2568:2570:2635:2682:2685:2691:2693:2703:2741:2827:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3354:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4120:4250:4321:4605:4860:5007:6117:6119:6261:7875:7903:8603:8957:9010:9025:9163:9177:10004:11658:12379:12740:13139:13161:13229, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:26, LUA_SUMMARY:none X-HE-Tag: wax62_3160f9a61ed45 X-Filterd-Recvd-Size: 9608 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf11.hostedemail.com (Postfix) with ESMTPA; Tue, 5 Jun 2018 15:25:39 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1c965083b32967a55b0041c0a7f18ad2" Date: Tue, 05 Jun 2018 17:25:38 +0200 From: Peter van der Stok To: Carsten Bormann Cc: core , ace Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> References: <152820873549.19149.17710091826447318076.idtracker@ietfa.amsl.com> <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.135.186] Archived-At: Subject: Re: [Ace] [core] New Version of draft-fossati-core-multipart-ct-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 15:25:45 -0000 --=_1c965083b32967a55b0041c0a7f18ad2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Carsten et al. I have looked at the multipart draft, and I am happy to see that the CBOR array is maintained as proposed in est-coaps. So now we have two drafts that both propose an almost identical new media type. The choice will be determined by the delay needed to (pre-)register the new media type. Will anyone start doing that for the multipart draft within a foreseeable delay. If not, I am happy to pre-register the new media type as specified in coaps-est to avoid delaying est-coaps. Looking forward to your reaction, many thanks for your trouble to create an indenpendent draft. peter Carsten Bormann schreef op 2018-06-05 16:55: > In https://github.com/SanKumar2015/EST-coaps/pull/50, Klaus has proposed to introduce a media type for efficiently combining multiple representations, along with the Content-Format numbers of their media types, into a single representation. > > I believe we have needed such a media type in other places, so I have extracted the content of that PR, and revved draft-fossati-core-multipart-ct (of 2013 vintage) with that. This would give us a media type multipart/core for general use. (Thanks are due to Klaus and Thomas for helping me with this little exercise.) > > CoAP-EST is due to be finished very soon, and extracting this media type from the CoAP-EST draft should only be done if we can avoid creating a hazard for CoAP-EST to be delayed by this. > > I don't see such a hazard unless we are having fundamental problems with the approach (but do accept its limited use in the CoAP-EST space). > So it would be useful to get some quick reactions on whether we can go ahead with this. > > If you don't want to read the draft right now, its technical content is: > multipart-core = [* multipart-part] > multipart-part = (type: uint .size 2, part: bytes / null) > > (Where "type" is the content-format identifier.) > > Grüße, Carsten > >> Name: draft-fossati-core-multipart-ct >> Revision: 04 >> Title: Multipart Content-Format for CoAP >> Document date: 2018-06-05 >> Group: Individual Submission >> Pages: 5 >> URL: https://www.ietf.org/internet-drafts/draft-fossati-core-multipart-ct-04.txt >> Status: https://datatracker.ietf.org/doc/draft-fossati-core-multipart-ct/ >> Htmlized: https://tools.ietf.org/html/draft-fossati-core-multipart-ct-04 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-fossati-core-multipart-ct >> Diff: https://www.ietf.org/rfcdiff?url2=draft-fossati-core-multipart-ct-04 >> >> Abstract: >> This memo defines multipart/core, an application-independent media- >> type that can be used to combine (even recursively) several different >> media types into a single CoAP message-body with minimal framing >> overhead, along with a CoAP Content-Format identifier. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=_1c965083b32967a55b0041c0a7f18ad2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Carsten et al.

I have looked at the multipart draft, and I am= happy to see that the CBOR array is maintained as proposed in est-coaps.So now we have two drafts that both propose an almost identical new med= ia type.

The choice will be determined by the delay needed to (p= re-)register the new media type.
Will anyone start doing that for the = multipart draft within a foreseeable delay.
If not, I am happy to pre-= register the new media type as specified in coaps-est to avoid delaying est= -coaps.

Looking forward to your reaction,

many thanks= for your trouble to create an indenpendent draft.

peter

Carsten Bormann schreef op 2018-06-05 16:55:

= In https://github.com/SanKumar2015/EST-coaps/pull/5= 0, Klaus has proposed to introduce a media type for efficiently combini= ng multiple representations, along with the Content-Format numbers of their= media types, into a single representation.

I believe we have n= eeded such a media type in other places, so I have extracted the content of= that PR, and revved draft-fossati-core-multipart-ct (of 2013 vintage) with= that.  This would give us a media type multipart/core for general use= =2E  (Thanks are due to Klaus and Thomas for helping me with this litt= le exercise.)

CoAP-EST is due to be finished very soon, and ext= racting this media type from the CoAP-EST draft should only be done if we c= an avoid creating a hazard for CoAP-EST to be delayed by this.

= I don't see such a hazard unless we are having fundamental problems with th= e approach (but do accept its limited use in the CoAP-EST space).
So = it would be useful to get some quick reactions on whether we can go ahead w= ith this.

If you don't want to read the draft right now, its te= chnical content is:
   multipart-core =3D [* multipart= -part]
   multipart-part =3D (type: uint .size 2, part= : bytes / null)

(Where "type" is the content-format identifier= =2E)

Grüße, Carsten


Name:        draft-= fossati-core-multipart-ct
Revision:    04
Title:=        Multipart Content-Format for CoA= P
Document date:    2018-06-05
Group:  &nbs= p;     Individual Submission
Pages:  &n= bsp;     5
URL:     &nbs= p;      https://www.ietf.org/internet-drafts/draft-fossati-core-multip= art-ct-04.txt
Status:        &= nbsp;https://datatracker.ietf.org/d= oc/draft-fossati-core-multipart-ct/
Htmlized:    &= nbsp;  https://tools.ietf.or= g/html/draft-fossati-core-multipart-ct-04
Htmlized:   &= nbsp;   https://= datatracker.ietf.org/doc/html/draft-fossati-core-multipart-ct
Dif= f:           https://www.ietf.org/rfcdiff?url2=3Ddraft-= fossati-core-multipart-ct-04

Abstract:
  Th= is memo defines multipart/core, an application-independent media-
&nb= sp; type that can be used to combine (even recursively) several differ= ent
  media types into a single CoAP message-body with mini= mal framing
  overhead, along with a CoAP Content-Format id= entifier.


_______________________________________________
core mai= ling list
core@iet= f.org
https://www.ietf.org/mailman/listinfo/core<= /a>
--=_1c965083b32967a55b0041c0a7f18ad2-- From nobody Tue Jun 5 11:04:42 2018 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 DD4971292AD; Tue, 5 Jun 2018 11:04:40 -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 NL0fqSoZWiAm; Tue, 5 Jun 2018 11:04:39 -0700 (PDT) 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 464CC126F72; Tue, 5 Jun 2018 11:04:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B25020091; Tue, 5 Jun 2018 14:18:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A8D7D2F8F; Tue, 5 Jun 2018 14:04:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A6D1C2F86; Tue, 5 Jun 2018 14:04:03 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: core , ace In-Reply-To: <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> References: <152820873549.19149.17710091826447318076.idtracker@ietfa.amsl.com> <0CBE522A-9BD8-48DD-BB2E-28D1663008CB@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] New Version of draft-fossati-core-multipart-ct-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jun 2018 18:04:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > I believe we have needed such a media type in other places, so I have > extracted the content of that PR, and revved > draft-fossati-core-multipart-ct (of 2013 vintage) with that. This > would give us a media type multipart/core for general use. (Thanks a= re > due to Klaus and Thomas for helping me with this little exercise.)=20 > CoAP-EST is due to be finished very soon, and extracting this media > type from the CoAP-EST draft should only be done if we can avoid > creating a hazard for CoAP-EST to be delayed by this. > I don=E2=80=99t see such a hazard unless we are having fundamental pr= oblems > with the approach (but do accept its limited use in the CoAP-EST > space). =20=20=20=20 > So it would be useful to get some quick reactions on whether we can go > ahead with this. I'm very happy, as I posted in another message before I sync'ed my inbox and got yours. I also have use of this multipart/core in the constrained extensions to BRSKI contained in 6tisch-dtsecurity-zerotouch. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxbQkYCLcPvd0N1lAQKxsgf/e2Y3iIUXpNtynT+CvjwX1Yd1KWfBeBuS ni93laKgCA4PKoxUqD9/CWpn+iwLWYyPOYucOCxfO4T88MwwGPnMqq0RISNtUtaN 5Cp9Nu7vgxaKh8PfOMjrJQ/l3T2pcsB2BH+t2oER5qh83pGovuRcfZrgs/Xoywjh Zq+820zZXRbv6m4tt9cF0FmTwALnfHVNDQzTh1EN3Yp+P/Gjls0am+PVTKI4kzUk 6phpsJtbsaZanqq6VJlEfNikd69LoEEF4Lie0Q9CWQwKeL9a+wb7NM8RjgpBZYXn nJu5zgiBSdTCgRW14gh+giCDAu1AUmHix7IbzVNCqUBYeNUc6Ew8ww== =NOaa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 6 08:35:22 2018 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 1FF26130F6C; Wed, 6 Jun 2018 08:35:13 -0700 (PDT) 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.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152829931308.6220.6525208471336527637@ietfa.amsl.com> Date: Wed, 06 Jun 2018 08:35:13 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 15:35:14 -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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Sandeep S. Kumar Michael C. Richardson Martin Furuhed Shahid Raza Filename : draft-ietf-ace-coap-est-01.txt Pages : 36 Date : 2018-06-06 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows low-resource constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-01 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-01 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 Wed Jun 6 16:32:58 2018 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 D349F130E04 for ; Wed, 6 Jun 2018 16:32:53 -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 KrdhoTuGse3M for ; Wed, 6 Jun 2018 16:32:50 -0700 (PDT) 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 D9C6A130DFF for ; Wed, 6 Jun 2018 16:32:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D3B4C20090 for ; Wed, 6 Jun 2018 19:46:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4AC0D74; Wed, 6 Jun 2018 19:32:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 485973F for ; Wed, 6 Jun 2018 19:32:13 -0400 (EDT) From: Michael Richardson To: ace@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jun 2018 23:32:54 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable In draft-ietf-ace-coap-est, we would like to specify some mandatory to implement algorithms for DTLS. We write: The mandatory cipher suite for DTLS in EST-coaps is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the mandatory-to-implement cipher suite in CoAP. Additionally, the curve secp256r1 MUST be supported [RFC4492]; this curve is equivalent to the NIST P-256 curve. And this is fine for now, but we'd like to signal that Curve25519 should be considered as an alternative, but we don't want to make it a MUST *today*, and we don't want to force implementations 15 years down the road that have it to include secp256r1. IPsec(ME) has published things like: https://datatracker.ietf.org/doc/rfc82= 47/ which include language like: SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. MUST- This term means the same as MUST. However, it is expected at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST- algorithm, it will remain at least a SHOULD or a SHOULD- level. I don't think TLS has done this... maybe TLS plans to. We think that we'd like to use SHOULD+ for Curve25519 and MUST- for secp256r1, but we aren't sure that the WG will like us to use so many words as IPsec to say so. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxhu/YCLcPvd0N1lAQISUAf+M2WPsC3tBJ9EGCTci8mkIMJuE36KMXXx nOOfJxJLvMNXX3OcAEWVoFbQbpvBijCD1Xct/zklrcRyJKFocui2qcx+Mze6ES7n Wp/mPyNcNuclBkU5d1XBoqvkYdDO52xQSoBY+C1wLvyD8pLA6DkuDJqUSHosCUy7 tgMzJEzIY/0ZBwwf945Vkdk9xPNRvtf1Ny7+0O3GIYfZwg2O7c/5oyE9JuUTKiQC 89vpx+jp4AZKHBFA5O6EaR+t9VNPIY1fbyrNuYrkD9e2xbTdwNV2uVyd/cOMDbG8 P/ZQkNeP3negUSZmM6yObnrb20LVGINtNGgP9JXpQTvOKQMOLkuz0g== =+PjT -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 6 22:18:16 2018 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 D5900130E64 for ; Wed, 6 Jun 2018 22:18:12 -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 5hxmLraISlZ7 for ; Wed, 6 Jun 2018 22:18:09 -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 7560D12F18C for ; Wed, 6 Jun 2018 22:18:09 -0700 (PDT) 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 w575I5Bi008251; Thu, 7 Jun 2018 07:18:05 +0200 (CEST) Received: from [192.168.217.102] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 411Yhs4RpQzDXTB; Thu, 7 Jun 2018 07:18:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <13635.1528327933@localhost> Date: Thu, 7 Jun 2018 07:18:04 +0200 Cc: ace@ietf.org X-Mao-Original-Outgoing-Id: 550041483.6584851-b841a1f3bf68db193ccefa46867c023c Content-Transfer-Encoding: quoted-printable Message-Id: <9BEB6564-6096-46A2-B38A-81234D6ECEE3@tzi.org> References: <13635.1528327933@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 05:18:13 -0000 Hi Michael, On Jun 7, 2018, at 01:32, Michael Richardson = wrote: >=20 > We think that we'd like to use SHOULD+ for Curve25519 and MUST- for > secp256r1, Sounds good to me. > but we aren't sure that the WG will like us to use so many > words as IPsec to say so. Can we just reference those words? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 7 02:06:50 2018 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 D828E130EA9 for ; Thu, 7 Jun 2018 02:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 b8xp38Kig3tW for ; Thu, 7 Jun 2018 02:06:43 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8E8130EA0 for ; Thu, 7 Jun 2018 02:06:43 -0700 (PDT) Received: from wangari.tzi.org (dynamic-218-8.informatik.uni-bremen.de [134.102.218.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 9A5E020684; Thu, 7 Jun 2018 11:06:41 +0200 (CEST) From: Olaf Bergmann To: Michael Richardson Cc: ace@ietf.org References: <13635.1528327933@localhost> Date: Thu, 07 Jun 2018 11:06:41 +0200 In-Reply-To: <13635.1528327933@localhost> (Michael Richardson's message of "Wed, 06 Jun 2018 19:32:13 -0400") Message-ID: <87muw7q82m.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 09:06:46 -0000 Hello Michael, Michael Richardson writes: > Curve25519 should be considered as an alternative As we had this discussion at IETF-101 regarding the profile coap_dtls: What where your reasoning for Curve25519? (Especially vs. Ed25519?) Gr=C3=BC=C3=9Fe Olaf From nobody Thu Jun 7 06:49:20 2018 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 232FE1310CC for ; Thu, 7 Jun 2018 06:49:17 -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 1pPi3x0Z6s0v for ; Thu, 7 Jun 2018 06:49:14 -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 DA673130E06 for ; Thu, 7 Jun 2018 06:49:13 -0700 (PDT) X-AuditID: 1209190d-571ff70000007a29-c4-5b1937d86502 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 60.BC.31273.8D7391B5; Thu, 7 Jun 2018 09:49:12 -0400 (EDT) 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 w57DnBoU023967; Thu, 7 Jun 2018 09:49:11 -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 w57Dn72G018881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jun 2018 09:49:10 -0400 Date: Thu, 7 Jun 2018 08:49:07 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: ace@ietf.org Message-ID: <20180607134907.GM72167@kduck.kaduk.org> References: <13635.1528327933@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HKEL+t8MFpg/ASTE" Content-Disposition: inline In-Reply-To: <13635.1528327933@localhost> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA2VSbUgTYRznuTv1tnbj2ant2cwPTj+UsZkhZlERRbGkoIIgXGCnO91wO8fd HE4CF64EFbWPjqBcS0VtqKFGGsaIoiQoFSeFDCrETdD1ZiSk3Tl8gb79/r+3Pw/Pn8TpQJKW tHJOlucYmy5ZTtCy9Gz93BGN6dDMYl7R79UWvKgl1JZyCjMGAn8wo/feOH4JK5EfN7M2q4vl 807ekFs2NkaSHAvqWn98gvCANboJyEgEC9DQ917QBOQkDR9iKDg6mpIYBgBq7BomEsMMhj7O twApQsAcdKfhQ7KEk0XsaZ7GJZwGDaj75YLoIUkcQhQPl0l0KixEcyuRzSglbuuYbMckCw33 I9/f/AStQm86vhISxqELhfvbiURLBupeJyVaBg+g6an7mITTYTZ63hpKaQfQtyvt25X27aQT dC6aW49i/9EHUVfnEp7AJ1AwuEI8ACm9INNsr9PbGatNYMv1QjnDcSyvP2ywW50G1lwzBDY/ QEM9BevzxSEASaBTUJ6I2kQnMS7BbQ8BDYnp0il/NjLRyrJqs9vCCJZSvsbGCiGQI+76PND3 HmgJrppjdWkUM7XXRFNmxl3H8tVbtgyS0KmpKj8w0bCScbJVLOtg+S11H0nqEDVZqDHRKp6t ZGsrrDbnjoyRshBApEIsj0keSnAwdsFamdDfgiytmqqXBCgJlhpuOysdF6qauBkDavFZqVRY cinE09tOx8RiTCw24pvFTmZH0nqA98Xp2dffmKtBVbF9ZWj53erlzNyiY/5lZVv98E9Hz93w 4pdPj/1Zt7znf/RHFOOpz7rj/OCY8ehaM3a2tMQ1eKaJXuavRS8s1TemqTo7PRXeaPnYnnOB ivj18Z7Bi1eKDSOR1RGDxd01+6gvHOVuZ8aU3o1fsd4nBQblq4ZWHSFYmPxcnBeYf8Yiodc3 AwAA Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 13:49:18 -0000 --HKEL+t8MFpg/ASTE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 06, 2018 at 07:32:13PM -0400, Michael Richardson wrote: >=20 > In draft-ietf-ace-coap-est, we would like to specify some mandatory to > implement algorithms for DTLS. >=20 > We write: > The mandatory cipher suite for DTLS in EST-coaps is > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the > mandatory-to-implement cipher suite in CoAP. >=20 > Additionally, the curve secp256r1 MUST be supported [RFC4492]; this cu= rve > is equivalent to the NIST P-256 curve. >=20 > And this is fine for now, but we'd like to signal that Curve25519 should = be > considered as an alternative, but we don't want to make it a MUST *today*, > and we don't want to force implementations 15 years down the road that ha= ve > it to include secp256r1. >=20 > IPsec(ME) has published things like: https://datatracker.ietf.org/doc/rfc= 8247/ > which include language like: >=20 > SHOULD+ This term means the same as SHOULD. However, it is likely > that an algorithm marked as SHOULD+ will be promoted at > some future time to be a MUST. >=20 > SHOULD- This term means the same as SHOULD. However, an algorithm > marked as SHOULD- may be deprecated to a MAY in a future > version of this document. >=20 > MUST- This term means the same as MUST. However, it is expected > at some point that this algorithm will no longer be a MUST > in a future document. Although its status will be > determined at a later time, it is reasonable to expect that > if a future revision of a document alters the status of a > MUST- algorithm, it will remain at least a SHOULD or a > SHOULD- level. Unfortunately, I'm not a big fan of the "+/-" variants of RFC 2119 keywords. It seems more clear to me to actually write out in prose the current situation and future expectations. So, if you do end up going this route, please ensure that the shepherd writeup includes a justification of why it was chosen. -Ben --HKEL+t8MFpg/ASTE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlsZN84ACgkQKNmm82Tr dRJtqAwgzqDQMxvvcqot16vY0fHw+fhsEeHZYSTSWAa3qIlqRV/zYRt06qnDpyCO 1x59lrSqd+uk+I1USZSlvH6v6NfVtwIe1fcRLbOG1XlVaCIP/6GiBUSu+HRZVgQx WNs7KgA2WHGqRwKFVCoFMw45mK4evbwBwgQsjXmn9HRLIdzmUa6e4xeyp52KFROU wxtP73iZasmGP/S5Y0zx8n47xML5m7I4WfUq1VA1ilMBsAjqZCcGo6g+8w5/dvyo jgfEmk0iCliVz3zfG8jQ9zWNrnnS2DYCDK4zFTZ/ST20oDXfkhPS6IGBE2qPQBu3 7+bUyYM2wn2A7T1xXfyxjPYFRorGIs4LfWTyo4bFEK1MK6HO+Q1tHibP40+wNPQs tVuag419AYYPFqfarSEgYU2Z5bAmDO/U/PwLV7mLH2oSPVt4MvBsOaCAv6/kbgKf Tho1uCifp/U4EMf9j1uw1mKUWb9VKQfaKKuUht3AUJxV72sTzn4V8SpEAmET6QkZ tQlN4tMXEJCY9A== =lf2L -----END PGP SIGNATURE----- --HKEL+t8MFpg/ASTE-- From nobody Thu Jun 7 06:55:24 2018 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 14F43131123 for ; Thu, 7 Jun 2018 06:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 bN9iUPodbyMM for ; Thu, 7 Jun 2018 06:55:17 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0E91310EC for ; Thu, 7 Jun 2018 06:55:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C5D9B300A0C for ; Thu, 7 Jun 2018 09:55:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oepTRFSVnNPK for ; Thu, 7 Jun 2018 09:55:13 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 77214300A11; Thu, 7 Jun 2018 09:55:13 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F5530C32-9BA2-4AA2-9670-DEA62DCC1233"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 7 Jun 2018 09:55:19 -0400 In-Reply-To: <13635.1528327933@localhost> Cc: ace@ietf.org To: Michael Richardson References: <13635.1528327933@localhost> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 13:55:22 -0000 --Apple-Mail=_F5530C32-9BA2-4AA2-9670-DEA62DCC1233 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael: These words were first used by IPsec; see RFC 4307. They have gained = broader acceptance. I see no problem just using them here. Russ > On Jun 6, 2018, at 7:32 PM, Michael Richardson = wrote: >=20 >=20 > In draft-ietf-ace-coap-est, we would like to specify some mandatory to > implement algorithms for DTLS. >=20 > We write: > The mandatory cipher suite for DTLS in EST-coaps is > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the > mandatory-to-implement cipher suite in CoAP. >=20 > Additionally, the curve secp256r1 MUST be supported [RFC4492]; this = curve > is equivalent to the NIST P-256 curve. >=20 > And this is fine for now, but we'd like to signal that Curve25519 = should be > considered as an alternative, but we don't want to make it a MUST = *today*, > and we don't want to force implementations 15 years down the road that = have > it to include secp256r1. >=20 > IPsec(ME) has published things like: = https://datatracker.ietf.org/doc/rfc8247/ > which include language like: >=20 > SHOULD+ This term means the same as SHOULD. However, it is likely > that an algorithm marked as SHOULD+ will be promoted at > some future time to be a MUST. >=20 > SHOULD- This term means the same as SHOULD. However, an algorithm > marked as SHOULD- may be deprecated to a MAY in a future > version of this document. >=20 > MUST- This term means the same as MUST. However, it is expected > at some point that this algorithm will no longer be a MUST > in a future document. Although its status will be > determined at a later time, it is reasonable to expect = that > if a future revision of a document alters the status of a > MUST- algorithm, it will remain at least a SHOULD or a > SHOULD- level. >=20 > I don't think TLS has done this... maybe TLS plans to. > We think that we'd like to use SHOULD+ for Curve25519 and MUST- for > secp256r1, but we aren't sure that the WG will like us to use so many > words as IPsec to say so. >=20 > -- > ] 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 [ >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_F5530C32-9BA2-4AA2-9670-DEA62DCC1233 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCWxk5RwAKCRCK5O7Q9ZwR y+kjAKCN0/2p6oPCz33xrOJV+zX2zHO5lACfSY6niRIJ7bwlXkR5U5HQrI1TdSQ= =GX1S -----END PGP SIGNATURE----- --Apple-Mail=_F5530C32-9BA2-4AA2-9670-DEA62DCC1233-- From nobody Thu Jun 7 09:30:27 2018 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 567361310FD for ; Thu, 7 Jun 2018 09:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 6A7X1KkB3UvT for ; Thu, 7 Jun 2018 09:30:12 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on060b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::60b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39ED130FD1 for ; Thu, 7 Jun 2018 09:30:11 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=9yGTWl/CaIHCcBXLhk85K0Q0zdYxjFi5/6UzyWxlqt0=; b=Rb56kXAOZM5NZ46uqKdWXbgwzH7h1hdDIkYTwzeLk7cD42HxbiMggzzSEhZfdsNxcUOYzR6AkeQg6d/x4Wjnq7y/YtUL4ixFI5E1CuFQWGB5kVkTkdNDXSr1TJaAQFWigjT72/+nfMlB2z4n6DlEt5Jzux7ucodDjRHzrL6SVnQ= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1887.eurprd08.prod.outlook.com (10.173.73.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.16; Thu, 7 Jun 2018 16:30:09 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0820.015; Thu, 7 Jun 2018 16:30:09 +0000 From: Hannes Tschofenig To: Russ Housley , Michael Richardson CC: "ace@ietf.org" Thread-Topic: [Ace] How to specify DTLS MTI in COAP-EST Thread-Index: AQHT/e65x8uyz3CYSUqqld4MOn23DqRU0nmAgAAqbVA= Date: Thu, 7 Jun 2018 16:30:08 +0000 Message-ID: References: <13635.1528327933@localhost> 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: [195.149.223.146] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1887; 7:vQUjM4twshBK2E63CFULUJVNWGO4I+Jxp7hrE+kC92PQQSAdZ3KlTZA0suwW/7h50yV1V3c2mVPl6kDxW8lS4CsYqEYpx6vFRJg4z1omGDz4/VW3VqO83IPU4CKX6re7AiOpFBstvSWXH3Zo7bpsQcW1bHCLvCkcbnhFQ0dAyylJCy5glgEJOSuy3oh3YKeQQcSdomE/fS03u7Ry4sIQtuGA3PJB3c3z7G1A7w1EDYRaeT/lF2GmPu3woC0eAERH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1887; x-ms-traffictypediagnostic: VI1PR0801MB1887: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1887; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1887; x-forefront-prvs: 06968FD8C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39860400002)(346002)(39380400002)(396003)(13464003)(199004)(189003)(40434004)(72206003)(3846002)(6116002)(3660700001)(26005)(478600001)(486006)(7696005)(110136005)(33656002)(6246003)(6506007)(99286004)(105586002)(53546011)(53936002)(186003)(6306002)(9686003)(316002)(966005)(476003)(102836004)(106356001)(2906002)(97736004)(66066001)(76176011)(59450400001)(446003)(5660300001)(5250100002)(5890100001)(3280700002)(11346002)(8936002)(81156014)(81166006)(8676002)(4326008)(55016002)(25786009)(14454004)(86362001)(68736007)(305945005)(229853002)(7736002)(2900100001)(74316002)(6436002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1887; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: i0V6DhrzkYhgnkunPNgwmqWikAoORytACtMAH5tP2qaxQyvvsbTxip4FWi0pYjfYzDkWfAO7AY2cJ2AaFw6PxBwVUy/QsF69Wn22fDarqdRQOLW2LEJp5lbJVY8LvAo1sG20s7H7Qo41NRRvWW+x5EgsIQEFgyarmuBPjww3n4GAorD7wCvO36lnDjw7fIJG spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: d165c395-522a-49ab-c581-08d5cc93ef53 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: d165c395-522a-49ab-c581-08d5cc93ef53 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2018 16:30:08.9046 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1887 Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 16:30:17 -0000 Hi Russ, Hi Michael, why don't you just reference https://tools.ietf.org/html/rfc7925? I am not a big fan of making all sorts of different crypto recommendations = in our specs that differ slightly. Ciao Hannes PS: Next time someone suggests the use of a new crypto algorithm I will dem= and that they also implement one themselves. -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Russ Housley Sent: 07 June 2018 15:55 To: Michael Richardson Cc: ace@ietf.org Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST Michael: These words were first used by IPsec; see RFC 4307. They have gained broad= er acceptance. I see no problem just using them here. Russ > On Jun 6, 2018, at 7:32 PM, Michael Richardson wr= ote: > > > In draft-ietf-ace-coap-est, we would like to specify some mandatory to > implement algorithms for DTLS. > > We write: > The mandatory cipher suite for DTLS in EST-coaps is > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the > mandatory-to-implement cipher suite in CoAP. > > Additionally, the curve secp256r1 MUST be supported [RFC4492]; this cur= ve > is equivalent to the NIST P-256 curve. > > And this is fine for now, but we'd like to signal that Curve25519 > should be considered as an alternative, but we don't want to make it a > MUST *today*, and we don't want to force implementations 15 years down > the road that have it to include secp256r1. > > IPsec(ME) has published things like: > https://datatracker.ietf.org/doc/rfc8247/ > which include language like: > > SHOULD+ This term means the same as SHOULD. However, it is likely > that an algorithm marked as SHOULD+ will be promoted at > some future time to be a MUST. > > SHOULD- This term means the same as SHOULD. However, an algorithm > marked as SHOULD- may be deprecated to a MAY in a future > version of this document. > > MUST- This term means the same as MUST. However, it is expected > at some point that this algorithm will no longer be a MUST > in a future document. Although its status will be > determined at a later time, it is reasonable to expect that > if a future revision of a document alters the status of a > MUST- algorithm, it will remain at least a SHOULD or a > SHOULD- level. > > I don't think TLS has done this... maybe TLS plans to. > We think that we'd like to use SHOULD+ for Curve25519 and MUST- for > secp256r1, but we aren't sure that the WG will like us to use so many > words as IPsec to say so. > > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > > > _______________________________________________ > 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 Thu Jun 7 09:40:21 2018 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 408E4130F5E for ; Thu, 7 Jun 2018 09:40:17 -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 N6k3EhjfjuqP for ; Thu, 7 Jun 2018 09:40:14 -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 B489B130F62 for ; Thu, 7 Jun 2018 09:40:13 -0700 (PDT) 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 w57Ge8R6003753; Thu, 7 Jun 2018 18:40:08 +0200 (CEST) Received: from sev.fritz.box (p5B3D0271.dip0.t-ipconnect.de [91.61.2.113]) (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 411rqq6t7FzDXbw; Thu, 7 Jun 2018 18:40:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Thu, 7 Jun 2018 18:40:07 +0200 Cc: Russ Housley , Michael Richardson , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 550082405.723434-ca402d0570fa2c8899e83c729189c5c4 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13635.1528327933@localhost> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 16:40:18 -0000 On Jun 7, 2018, at 18:30, Hannes Tschofenig = wrote: >=20 > why don't you just reference https://tools.ietf.org/html/rfc7925? That describes the status of mid-2016. Can we do something forward-looking? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 7 09:50:59 2018 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 9CF1E130F6C for ; Thu, 7 Jun 2018 09:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 vvTUj9k2Cfeb for ; Thu, 7 Jun 2018 09:50:50 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on062d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930E7130FD7 for ; Thu, 7 Jun 2018 09:50:49 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=9XKwgOcLXWrpyyFmi+CVy/BG01yKyQ6mlOMr8KctUYw=; b=kYqhqRXFDEg9VviLXB+3Y2tn3/Sp5tsDbeAiL7p6t8NiBkj69yh99CuK1giCaDv3k03krcAP+CD46+RO2DrPaKoPpOih/65d5iODJbQQso1d37BKNP86MJ1YYJYl6thDU9cBNGbsMQHoSvL+yNLZn08Kho5HV8/7DczvIanMqOI= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1679.eurprd08.prod.outlook.com (10.168.66.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.13; Thu, 7 Jun 2018 16:50:41 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0820.015; Thu, 7 Jun 2018 16:50:40 +0000 From: Hannes Tschofenig To: Carsten Bormann CC: Russ Housley , Michael Richardson , "ace@ietf.org" Thread-Topic: [Ace] How to specify DTLS MTI in COAP-EST Thread-Index: AQHT/e65x8uyz3CYSUqqld4MOn23DqRU0nmAgAAqbVCAAAOfgIAAAiRQ Date: Thu, 7 Jun 2018 16:50:40 +0000 Message-ID: References: <13635.1528327933@localhost> 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: [195.149.223.146] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1679; 7:WFQHfDNsdSfI/MQoh1OermjwtmhPs5W7eX2tQK53R+WwplK8RPNwEtZzv5rvBxErocItjHef9njGkwxV/NOWI6SN5bMmZwpO9j6ijaj8MvLHMgFlS1z00UYzAZVa+kimOnq96MA31Clvdc4twP7iDgw18SPT2lbYkVUO5ihHpxGa6LM7saE+Y+Xm8Mks2QBpQne4voioEZ02eUEv406WvLauFWemMhANcZrF2nkxgZ3XDnJWQDNmaLG2gwCvTaXW x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1679; x-ms-traffictypediagnostic: VI1PR0801MB1679: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1679; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1679; x-forefront-prvs: 06968FD8C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(376002)(39860400002)(39380400002)(13464003)(199004)(189003)(40434004)(53546011)(59450400001)(6506007)(76176011)(102836004)(14454004)(966005)(72206003)(7696005)(99286004)(93886005)(54906003)(478600001)(316002)(68736007)(8936002)(81166006)(81156014)(8676002)(476003)(11346002)(446003)(7736002)(86362001)(486006)(105586002)(186003)(305945005)(33656002)(26005)(74316002)(5890100001)(5250100002)(106356001)(6116002)(3846002)(97736004)(3660700001)(3280700002)(2906002)(66066001)(53936002)(6306002)(9686003)(25786009)(6436002)(2900100001)(6246003)(55016002)(4326008)(229853002)(5660300001)(6916009)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1679; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bCZrJe02xH0Sb45JgMncGk3M52ilEx7ObF6073fvVXbPAkbO9eXJgJ4ay9GdWyr3BJxZyE3Mzg0cm84Qxap6ZaNvP4rnjRXXDF3VoSiHrmxyMV4a5+AmLRlv410EEN5I6L9FuajNJHbr6oQfA/dLQjNlstiFt9b8mwKsT4ddf0KS8GguT3p2W9JYurEN6GY9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 05cdb0e5-a9e0-4628-8432-08d5cc96cd9e X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 05cdb0e5-a9e0-4628-8432-08d5cc96cd9e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2018 16:50:40.8890 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1679 Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 16:50:56 -0000 SW4gcHJvZHVjdHMgY3J5cHRvIGRvZXMgbm90IGNoYW5nZSB0aGF0IGZhc3QgZ2l2ZW4gdGhlIGxp ZmV0aW1lIG9mIElvVCBkZXZpY2VzIGFuZCB0aGUgaGFyZHdhcmUgc3VwcG9ydCBmb3IgaXQuIE91 ciBjdXN0b21lcnMgYXJlIGFza2luZyBmb3IgTklTVCBjZXJ0aWZpZWQgY3J5cHRvLg0KDQpDaWFv DQpIYW5uZXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9y bWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10NClNlbnQ6IDA3IEp1bmUgMjAxOCAxODo0MA0KVG86 IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogUnVzcyBIb3VzbGV5OyBNaWNoYWVsIFJpY2hhcmRzb247 IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIEhvdyB0byBzcGVjaWZ5IERUTFMgTVRJ IGluIENPQVAtRVNUDQoNCk9uIEp1biA3LCAyMDE4LCBhdCAxODozMCwgSGFubmVzIFRzY2hvZmVu aWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+IHdyb3RlOg0KPg0KPiB3aHkgZG9uJ3QgeW91 IGp1c3QgcmVmZXJlbmNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTI1Pw0KDQpU aGF0IGRlc2NyaWJlcyB0aGUgc3RhdHVzIG9mIG1pZC0yMDE2Lg0KDQpDYW4gd2UgZG8gc29tZXRo aW5nIGZvcndhcmQtbG9va2luZz8NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Thu Jun 7 10:12:20 2018 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 337B3131136 for ; Thu, 7 Jun 2018 10:12:13 -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 BJLmNez7OMeJ for ; Thu, 7 Jun 2018 10:12:10 -0700 (PDT) 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 B9150130F6F for ; Thu, 7 Jun 2018 10:12:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8B11C20090; Thu, 7 Jun 2018 13:25:40 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E9F5B3033; Thu, 7 Jun 2018 13:11:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E783F3032; Thu, 7 Jun 2018 13:11:33 -0400 (EDT) From: Michael Richardson To: Olaf Bergmann cc: ace@ietf.org In-Reply-To: <87muw7q82m.fsf@tzi.org> References: <13635.1528327933@localhost> <87muw7q82m.fsf@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 17:12:14 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Olaf Bergmann wrote: > Michael Richardson writes: >> Curve25519 should be considered as an alternative > As we had this discussion at IETF-101 regarding the profile coap_dtls: > What where your reasoning for Curve25519? (Especially vs. Ed25519?) AFAIK, Curve25519 is about the PFS/key-agreement. Ed25519 is about authentication of the end-points, and depends upon what's in the certificates (if any are used) to validate the end points. CoAP-EST does not say anything actually about authentication; i.e. how we get the Secure Transport. It's out of scope for this document. (But, in scope for draft-ietf-6tisch-dtsecure-zerotouch-join ) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxlnQoCLcPvd0N1lAQJX1wf9HnR7hkuUBleGEVS8wLhdcEzyNs9iDasA czJJYXlLQmm/bzaR+siZKJ5nDp/Am5JXAwJ1Pro/2JL1AUIJ9MLiFPg72ar67oKc ceIQOnM/qj76A7DG3QgMPFX55BmpyUMdVqAsZIIWKG2lpI40JtXCGmD0P/G6d0oX E3CWD1TrU15m7LzfXwkUsGuxILIRw3dxV2rbMAYasv/oNTxQQMWB9ePB1ZG+5BUz HU3KTX43Gk0CC2FxV+ALO/hw5nzWUbW38P7waXCEtfI5NujqCi75xgVc3srkC5KO GG3zrG0qAKPRI834wsFjYv3FygJ8itte8twC8EEsBa1NhP5WlYKrrA== =j46L -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 7 10:15:30 2018 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 65250130F75 for ; Thu, 7 Jun 2018 10:15:23 -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 rbTGiH8PqMjc for ; Thu, 7 Jun 2018 10:15:17 -0700 (PDT) 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 ABC36131143 for ; Thu, 7 Jun 2018 10:15:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 897FD20090; Thu, 7 Jun 2018 13:28:47 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E33F93033; Thu, 7 Jun 2018 13:14:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E0EBF3032; Thu, 7 Jun 2018 13:14:40 -0400 (EDT) From: Michael Richardson To: Russ Housley cc: ace@ietf.org In-Reply-To: References: <13635.1528327933@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 17:15:24 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Russ Housley wrote: > These words were first used by IPsec; see RFC 4307. They have gained > broader acceptance. I see no problem just using them here. Yes, but they aren't in an RFC2119-like document that we can simply cite, a= nd I'm not sure if the TLS reviewers will like them. Ben doesn't like them for in= stance. I would probably just write: SHOULD+/SHOULD-/MUST- are used in the same way as in RFC8247 >> On Jun 6, 2018, at 7:32 PM, Michael Richardson wrote: >>=20 >>=20 >> In draft-ietf-ace-coap-est, we would like to specify some mandatory = to >> implement algorithms for DTLS. >>=20 >> We write: >> The mandatory cipher suite for DTLS in EST-coaps is >> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the >> mandatory-to-implement cipher suite in CoAP. >>=20 >> Additionally, the curve secp256r1 MUST be supported [RFC4492]; this = curve >> is equivalent to the NIST P-256 curve. >>=20 >> And this is fine for now, but we'd like to signal that Curve25519 sh= ould be >> considered as an alternative, but we don't want to make it a MUST *t= oday*, >> and we don't want to force implementations 15 years down the road th= at have >> it to include secp256r1. >>=20 >> IPsec(ME) has published things like: https://datatracker.ietf.org/do= c/rfc8247/ >> which include language like: >>=20 >> SHOULD+ This term means the same as SHOULD. However, it is likely >> that an algorithm marked as SHOULD+ will be promoted at >> some future time to be a MUST. >>=20 >> SHOULD- This term means the same as SHOULD. However, an algorithm >> marked as SHOULD- may be deprecated to a MAY in a future >> version of this document. >>=20 >> MUST- This term means the same as MUST. However, it is expected >> at some point that this algorithm will no longer be a MUST >> in a future document. Although its status will be >> determined at a later time, it is reasonable to expect that >> if a future revision of a document alters the status of a >> MUST- algorithm, it will remain at least a SHOULD or a >> SHOULD- level. >>=20 >> I don't think TLS has done this... maybe TLS plans to. >> We think that we'd like to use SHOULD+ for Curve25519 and MUST- for >> secp256r1, but we aren't sure that the WG will like us to use so many >> words as IPsec to say so. >>=20 >> -- >> ] Never tell me the odds! | ipv6 mesh = networks [ >> ] Michael Richardson, Sandelman Software Works | network ar= chitect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxln/oCLcPvd0N1lAQLuBgf8DoGvl3V/WbJEl/YxNq76MwpidFesRVaH gvCZw1YnOoQnuXHM3jvJVRzjE0IDlEntl0VRJgCGa7p+W9ma/d6beDmf00bqge5J hfE1xC1Oh5aLA8ZBTCdquTeUwUnOXiU86s+iP3uG0c+pOOQzzFF7yuPMhFCZ08rA yTg162tfUT+mYs8C2+b9Bb2xumJOf8UUyzOqhYb5jyR0VB/uiFzShqUfb4C5zwnf 5J7ouN7B4MkPF4TmKaCCsiK4BP0XjjXrI2gVaHfNKEAAa8gFCeeAFvX18mHdPv5V Xp0WiUKK0e7A8cZ6wuAfSjRRVJ82v51QTTq8WtXOHLu0QNFh199dHg== =EQxT -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 7 10:42:01 2018 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 152E2130F75 for ; Thu, 7 Jun 2018 10:41:58 -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 S57dgBM5nWgZ for ; Thu, 7 Jun 2018 10:41:55 -0700 (PDT) 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 D9BF4131149 for ; Thu, 7 Jun 2018 10:41:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2143020090; Thu, 7 Jun 2018 13:55:24 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6B47B3033; Thu, 7 Jun 2018 13:41:17 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 687FE3032; Thu, 7 Jun 2018 13:41:17 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig , "ace\@ietf.org" In-Reply-To: References: <13635.1528327933@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 17:41:59 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > why don't you just reference https://tools.ietf.org/html/rfc7925? Ignorance :-) Thank you, I think that we will reference it then; Section 4.4 includes: At the time of writing, the recommended curve is secp256r1, and the use of uncompressed points follows the recommendation in CoAP. Note that standardization for Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for this curve will likely be required in the future. which is what we want to say anyway. > I am not a big fan of making all sorts of different crypto > recommendations in our specs that differ slightly.=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxluOoCLcPvd0N1lAQKUXQgAiPJcz4HuoSPSycQBtqOrwDY0QpOFLhtI EifuFP1pSekeToT1tQN+DOtS1v15cqZEnCbpnQe3qOUoJS5or0nKUEkY4RAEQgNd s0iWfZoW3vcvzAnaq3wUdkFQ7LkLpF5ZWrJ/Z2lgjNHUuNPWY4wudnDSBFj/yKRv ZpJYlpyvtKGsObz4yygt9aqUbVuTaThVnIU2kZknCXdiVTtnhMVTefmstPl3N9oY eNiTWWiFFVMnmFYGZkF9bTY8ALw9h7uho05ffXjf68BVTUENE1l1woU+KFh8DLq5 TisuUFVnf7WOYAZ+4qULtIOayyqEb49Ipmh1IWh8Je82pTne34p9bw== =kgEX -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 7 13:21:23 2018 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 040B1130934 for ; Thu, 7 Jun 2018 13:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 2Cv8HZVUTiHg for ; Thu, 7 Jun 2018 13:21:17 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 11EE4127332 for ; Thu, 7 Jun 2018 13:21:17 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id n3-v6so13070906ota.5 for ; Thu, 07 Jun 2018 13:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yhrrDMgbgm1mFd94f42UOlD4rkpKXSaz9d/VSG7nQ/s=; b=R6SUlsQ4STaWOjHV+xEf29tzBMJaY6CQaQH2jJmxpGhhcsxuNS3Ffl+eCRRJehfAXH vRttPyYIVzD3V9r0mHB3AoIEhtn2M+H5TcJtdIQOgSYugLzgaUATAU4IuW+yx4mN9RBN LwijumkDnAnTmxA19OzqNNYy34Y+S+wxWWbdqPFeMxIoqDfU1jMYV4ZY3DUl4DkbxTeQ iP+pA4CgqjEO3a3H13ruZkhg9Z+F8NXSRwUytNbbzbWPb8ikjxEPNGFxIhcpSd457D7+ lPX1+BghOUGZp41iltnQdqw9jkqtGNgPZWMKYk4xKeY3Lqw+4sDAS3oxtTf0bhvHlO3m V6uQ== 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=yhrrDMgbgm1mFd94f42UOlD4rkpKXSaz9d/VSG7nQ/s=; b=rPym6RDCV3kdjwb0JewJYy3RUeB5C3CLC3bQnvzoJlxge1JUKo6FWGX9vMkUsDGKTU /zcZATYhfoK/uSplgFxcHD+C0OyQrksrHVAyOEefgMgdIgfVcPZb39eIk5xg7lrfiglU w65syb7V4s4p95YKnWqjWunq1wU451JV+sYDke/CW6+cbnCjZffJ+QKpXJbasiCuu4KV owyEw0VkSpTjJlUoWyjOFLrQbP0kFdLvR7m+ewKP6mBjTPvuul64FOL9E4lqE/bIrmgL JT+cybiQplGUTY26H0byeIRoApDYvhh2nTTXtw0hY7ASScQHJc5hDWgd5ENWdn+4fdGN wYaA== X-Gm-Message-State: APt69E1CRuAjzTvU01AipURhcGXbsNZUH+i4D5fOTg4cNhjESkzS2IXJ aZYwQatxSO7io3gj+onDdA5dJjLO8VLe3pAXgxIt3x+9 X-Google-Smtp-Source: ADUXVKINzHHYYEN4TVRsokdm2Dd2Vq2Qdpkx2QicxTNl1vH1DYbY3Lzl3J/F9dcnBvE6ZQvQdGJTMnLM8hbsSYZSsuA= X-Received: by 2002:a9d:55d0:: with SMTP id z16-v6mr2097501oti.176.1528402876404; Thu, 07 Jun 2018 13:21:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 13:20:35 -0700 (PDT) In-Reply-To: <12464.1528393277@localhost> References: <13635.1528327933@localhost> <12464.1528393277@localhost> From: Eric Rescorla Date: Thu, 7 Jun 2018 13:20:35 -0700 Message-ID: To: Michael Richardson Cc: Hannes Tschofenig , "ace@ietf.org" Content-Type: multipart/alternative; boundary="000000000000859eba056e1306ea" Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 20:21:21 -0000 --000000000000859eba056e1306ea Content-Type: text/plain; charset="UTF-8" TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS, so you should just use words if you want to convey these points. With that said, I don't really understand the objective here: we're generally moving towards the CFRG curves, so what's the reasoning for the P256 MUST and why do you think that will change. -Ekr On Thu, Jun 7, 2018 at 10:41 AM, Michael Richardson wrote: > > Hannes Tschofenig wrote: > > why don't you just reference https://tools.ietf.org/html/rfc7925? > > Ignorance :-) > Thank you, I think that we will reference it then; > > Section 4.4 includes: > > At the time of writing, the > recommended curve is secp256r1, and the use of uncompressed points > follows the recommendation in CoAP. Note that standardization for > Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for > this curve will likely be required in the future. > > which is what we want to say anyway. > > > I am not a big fan of making all sorts of different crypto > > recommendations in our specs that differ slightly. > > -- > ] 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 [ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --000000000000859eba056e1306ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TBH, I'm not a fan of SHOULD+, etc., and they'= ;re pretty alien to TLS, so you should just use words if you want to convey= these points.

With that said, I don't rea= lly understand the objective here: we're generally moving towards the C= FRG curves, so what's the reasoning for the P256 MUST and why do you th= ink that will change.

-Ekr



On Thu, Jun 7, 2018 at 10:41 AM, Michael Richardson <= mcr+ietf@sandelm= an.ca> wrote:

Hannes Tschofenig <Hannes.T= schofenig@arm.com> wrote:
=C2=A0 =C2=A0 > why don't you just reference https://tools= .ietf.org/html/rfc7925?

Ignorance :-)
Thank you, I think that we will reference it then;

Section 4.4 includes:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 At the time of writing, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 recommended curve is secp256r1, and the use of = uncompressed points
=C2=A0 =C2=A0 =C2=A0 =C2=A0 follows the recommendation in CoAP.=C2=A0 Note = that standardization for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Curve25519 (for ECDHE) is ongoing (see [RFC7748= ]), and support for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this curve will likely be required in the futur= e.

which is what we want to say anyway.

=C2=A0 =C2=A0 > I am not a big fan of making all sorts of different cryp= to
=C2=A0 =C2=A0 > recommendations in our specs that differ slightly.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | network architect=C2=A0 [
]=C2=A0 =C2=A0 =C2=A0mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0ruby on rails=C2=A0 =C2=A0 [


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


--000000000000859eba056e1306ea-- From nobody Thu Jun 7 14:27:47 2018 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 234D7130FA2 for ; Thu, 7 Jun 2018 14:27:44 -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 I8tdUkRjq152 for ; Thu, 7 Jun 2018 14:27:38 -0700 (PDT) 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 F4032130DD6 for ; Thu, 7 Jun 2018 14:27:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CE2C320090; Thu, 7 Jun 2018 17:41:06 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 736843033; Thu, 7 Jun 2018 17:26:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 70EB03032; Thu, 7 Jun 2018 17:26:59 -0400 (EDT) From: Michael Richardson To: Eric Rescorla cc: Hannes Tschofenig , "ace\@ietf.org" In-Reply-To: References: <13635.1528327933@localhost> <12464.1528393277@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 07 Jun 2018 21:27:45 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS,= so > you should just use words if you want to convey these points. > With that said, I don't really understand the objective here: we're > generally moving towards the CFRG curves, so what's the reasoning for= the > P256 MUST and why do you think that will change. Because current generation of hardware and TPM modules has definite support for P256, and while some of the hardware assist out there can accelerate CF= RG curves as well or better: a) it's not universally true. b) it takes time to get the new code through a FIPS process. So, we want to say, P256 is if you must, and CFRG if you can on the constrained device. On a non-constrained CA side, P256 becomes a MUST because one needs to support the old devices, and CFRG becomes a MUST just as soon as one can get the code through the right processes. In any case, 7925 says EXACTLY this, so we are happy, and do not want to repeat things. > wrote: >>=20 >> Hannes Tschofenig wrote: >> > why don't you just reference https://tools.ietf.org/html/rfc7925? >>=20 >> Ignorance :-) >> Thank you, I think that we will reference it then; >>=20 >> Section 4.4 includes: >>=20 >> At the time of writing, the >> recommended curve is secp256r1, and the use of uncompressed points >> follows the recommendation in CoAP. Note that standardization for >> Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for >> this curve will likely be required in the future. >>=20 >> which is what we want to say anyway. >>=20 >> > I am not a big fan of making all sorts of different crypto >> > recommendations in our specs that differ slightly. >>=20 >> -- >> ] 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 [ >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 >>=20 > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxmjI4CLcPvd0N1lAQKTGgf+OtmgMTJPlyJ/DYIzXV6/ef7yb2ZY3t3c 5mm+yl+cSRQvt+h9BGopYbXiUo538HHdZKepSbcLbYxPwlQ2eiklJZsWPzuiJC/q 8KMeX8X/r7uC5ey4beC3lRNPR9yFJvE6QUQKhEmj+YOtBNoC4v4WbTDT8LpvJFBq rFD0OpMzV1QgC+FlqoWj4C9bcNB5vlWgGJpsPW4spuwsq97tkMpXbBWYI4D6qFqL Cu8pKqMIJtsmxfwPGYNnNDTe03wIMRa7RSifg8a2kCAAPUaPNgQrE/58N6EZdHqK TkJ/13casw+x/sodGaCqzFvqDwg19QOtygydwElvjsxCiKyJnxQjdg== =+UVV -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 7 22:10:34 2018 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 04F04130E14 for ; Thu, 7 Jun 2018 22:10:32 -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] 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 yvTQOhscg8Ky for ; Thu, 7 Jun 2018 22:10:29 -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 19CCF130E1F for ; Thu, 7 Jun 2018 22:10:28 -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 w585ANZV011036; Fri, 8 Jun 2018 07:10:23 +0200 (CEST) Received: from sev.fritz.box (p5B3D0187.dip0.t-ipconnect.de [91.61.1.135]) (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 4129TV5mStzDXgZ; Fri, 8 Jun 2018 07:10:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <31776.1528406819@localhost> Date: Fri, 8 Jun 2018 07:10:21 +0200 Cc: Eric Rescorla , Hannes Tschofenig , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 550127418.731071-cf3746d990adc9e31ebdf7641e4eff91 Content-Transfer-Encoding: quoted-printable Message-Id: <88E57C96-48FC-4D2B-A666-3363D67A1372@tzi.org> References: <13635.1528327933@localhost> <12464.1528393277@localhost> <31776.1528406819@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 08 Jun 2018 05:10:33 -0000 We had that discussion at the SUIT hackathon earlier this week, as well. To get actual interoperability there, of course, every test pair needs = to decide between P-256 and 25519 (and, maybe, use hash-based instead; = but that is more appropriate for firmware update than for other uses). The general observation was that we are seeing a much slower = displacement of P-256 by 25519 than we would have expected, say, a year = ago. So, indeed, RFC 7925 is continuing to describe the current situation. We can simply acknowledge that status quo. We can also express some normative intent to accelerate the transition. Or we can express an expectation that it will accelerate, without = actually expressing normative intent. Either one could be anchored at a specific date (say, 25519 becomes MTI = from 2020). As I said at the IoT-dir meeting in London, this is really the = discussion I would like to see now across all IoT groups. What do we want? Gr=C3=BC=C3=9Fe, Carsten > On Jun 7, 2018, at 23:26, Michael Richardson = wrote: >=20 >=20 > Eric Rescorla wrote: >> TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS, = so >> you should just use words if you want to convey these points. >=20 >> With that said, I don't really understand the objective here: we're >> generally moving towards the CFRG curves, so what's the reasoning for = the >> P256 MUST and why do you think that will change. >=20 > Because current generation of hardware and TPM modules has definite = support > for P256, and while some of the hardware assist out there can = accelerate CFRG > curves as well or better: > a) it's not universally true. > b) it takes time to get the new code through a FIPS process. >=20 > So, we want to say, P256 is if you must, and CFRG if you can on the > constrained device. >=20 > On a non-constrained CA side, P256 becomes a MUST because one needs to > support the old devices, and CFRG becomes a MUST just as soon as one > can get the code through the right processes. >=20 > In any case, 7925 says EXACTLY this, so we are happy, and do not want = to > repeat things. >=20 >> wrote: >=20 >>>=20 >>> Hannes Tschofenig wrote: >>>> why don't you just reference https://tools.ietf.org/html/rfc7925? >>>=20 >>> Ignorance :-) >>> Thank you, I think that we will reference it then; >>>=20 >>> Section 4.4 includes: >>>=20 >>> At the time of writing, the >>> recommended curve is secp256r1, and the use of uncompressed points >>> follows the recommendation in CoAP. Note that standardization for >>> Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for >>> this curve will likely be required in the future. >>>=20 >>> which is what we want to say anyway. >>>=20 >>>> I am not a big fan of making all sorts of different crypto >>>> recommendations in our specs that differ slightly. >>>=20 >>> -- >>> ] 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 [ >>>=20 >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>>=20 >>>=20 >=20 >> ---------------------------------------------------- >> Alternatives: >=20 >> ---------------------------------------------------- >=20 > --=20 > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jun 7 23:56:41 2018 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 820FB130E2C for ; Thu, 7 Jun 2018 23:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 ObNOUT4tN9iE for ; Thu, 7 Jun 2018 23:56:35 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0077.outbound.protection.outlook.com [104.47.0.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B009130DCB for ; Thu, 7 Jun 2018 23:56:33 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=NwcGXzxU4OHrNvqcjNVmsCr/bh/Wg4A/h53ODHalGLo=; b=COMboo/waFgg44UmV4VUSPgWpiB55EOV/WGHGKlLZX1jCXE5j9wT8eEGe4NwTcMUGAAaV1VS487fX7GT0mfMJlUkmpBq5hhg+EyIsq39KSQqCsqif9sBGhVlOht8xzIg5IpMHZ+QJCqN2Ty3yRe9dUpPDUwqbpVWjJQOrTb4klQ= Received: from AM5PR0801MB2097.eurprd08.prod.outlook.com (10.168.158.151) by AM5PR0801MB1379.eurprd08.prod.outlook.com (10.167.217.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.14; Fri, 8 Jun 2018 06:56:31 +0000 Received: from AM5PR0801MB2097.eurprd08.prod.outlook.com ([fe80::65ac:45dd:6b32:4853]) by AM5PR0801MB2097.eurprd08.prod.outlook.com ([fe80::65ac:45dd:6b32:4853%12]) with mapi id 15.20.0841.015; Fri, 8 Jun 2018 06:56:31 +0000 From: Hannes Tschofenig To: Eric Rescorla , Michael Richardson CC: "ace@ietf.org" Thread-Topic: [Ace] How to specify DTLS MTI in COAP-EST Thread-Index: AQHT/e65x8uyz3CYSUqqld4MOn23DqRU0nmAgAAqbVCAABS2gIAALIKAgACtKIA= Date: Fri, 8 Jun 2018 06:56:30 +0000 Message-ID: References: <13635.1528327933@localhost> <12464.1528393277@localhost> 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.115.197] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0801MB1379; 7:DQHIhCVWXFCl8q10LNaAzWcpzKdUvKL9wVW+ICvCW7z5zwMacxejiyrsRPsNCrgi7u6HbkIjCsQeSBFHWfyWZNYQrH5pxpSIMQ9aqKNrhqxRae7dt+GaoxvPWFCWE+9FPQcaxPIqwob8ll23OemCllnBNQhiefk97NsuCsJva/OOZO2JoTSGlSaZ3+SrcFTiJZvW6JX7pUyAOZgjEkdOjA+dXYvNNO0jSovvfPjSAyTtZRDExLceUrhhWyOPZNbC x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM5PR0801MB1379; x-ms-traffictypediagnostic: AM5PR0801MB1379: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM5PR0801MB1379; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0801MB1379; x-forefront-prvs: 06973FFAD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(396003)(39850400004)(39380400002)(51444003)(40434004)(199004)(189003)(5250100002)(486006)(97736004)(9686003)(3660700001)(25786009)(33656002)(74316002)(2906002)(81156014)(81166006)(8936002)(55016002)(478600001)(5890100001)(790700001)(66066001)(3846002)(6116002)(86362001)(6436002)(14454004)(72206003)(8676002)(6246003)(2900100001)(106356001)(105586002)(5660300001)(53936002)(68736007)(7696005)(76176011)(93886005)(26005)(966005)(606006)(229853002)(102836004)(110136005)(59450400001)(16297215004)(53546011)(3280700002)(6506007)(446003)(7736002)(11346002)(476003)(99286004)(236005)(6306002)(54896002)(186003)(316002)(4326008)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0801MB1379; H:AM5PR0801MB2097.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5lrXTzu5+nNG8+sHedYgh2eQWmYuqRJq90NJB0Olf1vlBJfqEBkyxcIeJzWkF+dQ0+H+nU7C9JlHCQkJZD4zzF1+CCgNdLHv9BTq/K8BppAvSRiL4cs5YeYW7hlRmU3xjTzk6aZL5siVIHp5rWllkMwufceycUBn7wMFwOncqhfUzJ1oVvIbXUgjkZYTVZ2q spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0801MB2097054338CC03563649549FFA7B0AM5PR0801MB2097_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: e7c6e281-80fd-4922-d6fd-08d5cd0cf71d X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7c6e281-80fd-4922-d6fd-08d5cd0cf71d X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2018 06:56:31.0341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1379 Archived-At: Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 08 Jun 2018 06:56:39 -0000 --_000_AM5PR0801MB2097054338CC03563649549FFA7B0AM5PR0801MB2097_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSBhcmUgbXkgdGhvdWdodHM6DQoNCg0KwrcgICAgICAgVGhpcyBncm91cCBvciBhbnkgb3Ro ZXIgSW9UIGdyb3VwIHNob3VsZCBub3QgY29tZSB1cCB3aXRoIHRoZWlyIG93biBhbGdvcml0aG0g cmVjb21tZW5kYXRpb25zLiBSZWFzb246IHdlIGFscmVhZHkgaGF2ZSBhIGdyb3VwIHdvcmtpbmcg b24gdGhlc2UgcmVjb21tZW5kYXRpb25zIC0gQ0ZSRw0KDQrCtyAgICAgICBUaGVyZSBpcyBubyBu ZWVkIHRvIHRhbGsgYWJvdXQgbmV3IGFsZ29yaXRobXMgcmVjb21tZW5kYXRpb25zLiBSZWFzb246 IHRoZSByZWNvbW1lbmRhdGlvbnMgaGF2ZSBhbHJlYWR5IGJlZW4gbWFkZSBieSB0aGUgQ0ZSRyBh bmQgdGhlIFRMUyAxLjMgc3BlYyBsaXN0cyB0aGVtLg0KDQrCtyAgICAgICBUaGUgcGFjZSBvZiBz d2l0Y2hpbmcgdG8gbmV3IGNyeXB0byBhbGdvcml0aG0gc2VlbXMgdG8gYmUgbXVjaCBzbG93ZXIg aW4gdGhlIElvVCB3b3JsZCAoZm9yIHRoZSBkaXNjdXNzZWQgcmVhc29ucykuIEkgZmVlbCB0aGVy ZSBpcyB2ZXJ5IGxpdHRsZSBtb3N0IG9mIHVzIGNhbiBkbyB0byBpbmZsdWVuY2UgdGhlIHBhY2Uu IFJlYXNvbjogdmVyeSBmZXcgZm9sa3Mgd29yayBvbiBpbXBsZW1lbnRhdGlvbnMgb2YgY3J5cHRv IGFsZ29yaXRobXMgZm9yIElvVCBkZXZpY2VzLg0KDQpDaWFvDQpIYW5uZXMNCg0KRnJvbTogRXJp YyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NClNlbnQ6IDA3IEp1bmUgMjAxOCAyMjoy MQ0KVG86IE1pY2hhZWwgUmljaGFyZHNvbg0KQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnOyBhY2VAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWNlXSBIb3cgdG8gc3BlY2lmeSBEVExTIE1USSBpbiBDT0FQ LUVTVA0KDQpUQkgsIEknbSBub3QgYSBmYW4gb2YgU0hPVUxEKywgZXRjLiwgYW5kIHRoZXkncmUg cHJldHR5IGFsaWVuIHRvIFRMUywgc28geW91IHNob3VsZCBqdXN0IHVzZSB3b3JkcyBpZiB5b3Ug d2FudCB0byBjb252ZXkgdGhlc2UgcG9pbnRzLg0KDQpXaXRoIHRoYXQgc2FpZCwgSSBkb24ndCBy ZWFsbHkgdW5kZXJzdGFuZCB0aGUgb2JqZWN0aXZlIGhlcmU6IHdlJ3JlIGdlbmVyYWxseSBtb3Zp bmcgdG93YXJkcyB0aGUgQ0ZSRyBjdXJ2ZXMsIHNvIHdoYXQncyB0aGUgcmVhc29uaW5nIGZvciB0 aGUgUDI1NiBNVVNUIGFuZCB3aHkgZG8geW91IHRoaW5rIHRoYXQgd2lsbCBjaGFuZ2UuDQoNCi1F a3INCg0KDQoNCk9uIFRodSwgSnVuIDcsIDIwMTggYXQgMTA6NDEgQU0sIE1pY2hhZWwgUmljaGFy ZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2E+ PiB3cm90ZToNCg0KSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208 bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90ZToNCiAgICA+IHdoeSBkb24n dCB5b3UganVzdCByZWZlcmVuY2UgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5MjU/ DQoNCklnbm9yYW5jZSA6LSkNClRoYW5rIHlvdSwgSSB0aGluayB0aGF0IHdlIHdpbGwgcmVmZXJl bmNlIGl0IHRoZW47DQoNClNlY3Rpb24gNC40IGluY2x1ZGVzOg0KDQogICAgICAgIEF0IHRoZSB0 aW1lIG9mIHdyaXRpbmcsIHRoZQ0KICAgICAgICByZWNvbW1lbmRlZCBjdXJ2ZSBpcyBzZWNwMjU2 cjEsIGFuZCB0aGUgdXNlIG9mIHVuY29tcHJlc3NlZCBwb2ludHMNCiAgICAgICAgZm9sbG93cyB0 aGUgcmVjb21tZW5kYXRpb24gaW4gQ29BUC4gIE5vdGUgdGhhdCBzdGFuZGFyZGl6YXRpb24gZm9y DQogICAgICAgIEN1cnZlMjU1MTkgKGZvciBFQ0RIRSkgaXMgb25nb2luZyAoc2VlIFtSRkM3NzQ4 XSksIGFuZCBzdXBwb3J0IGZvcg0KICAgICAgICB0aGlzIGN1cnZlIHdpbGwgbGlrZWx5IGJlIHJl cXVpcmVkIGluIHRoZSBmdXR1cmUuDQoNCndoaWNoIGlzIHdoYXQgd2Ugd2FudCB0byBzYXkgYW55 d2F5Lg0KDQogICAgPiBJIGFtIG5vdCBhIGJpZyBmYW4gb2YgbWFraW5nIGFsbCBzb3J0cyBvZiBk aWZmZXJlbnQgY3J5cHRvDQogICAgPiByZWNvbW1lbmRhdGlvbnMgaW4gb3VyIHNwZWNzIHRoYXQg ZGlmZmVyIHNsaWdodGx5Lg0KLS0NCl0gICAgICAgICAgICAgICBOZXZlciB0ZWxsIG1lIHRoZSBv ZGRzISAgICAgICAgICAgICAgICAgfCBpcHY2IG1lc2ggbmV0d29ya3MgWw0KXSAgIE1pY2hhZWwg UmljaGFyZHNvbiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzICAgICAgICB8IG5ldHdvcmsgYXJj aGl0ZWN0ICBbDQpdICAgICBtY3JAc2FuZGVsbWFuLmNhPG1haWx0bzptY3JAc2FuZGVsbWFuLmNh PiAgaHR0cDovL3d3dy5zYW5kZWxtYW4uY2EvICAgICAgICB8ICAgcnVieSBvbiByYWlscyAgICBb DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2Ug bWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk byBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBm b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_AM5PR0801MB2097054338CC03563649549FFA7B0AM5PR0801MB2097_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFt ZTppbTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjEyNTY5NDI2NDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjEyNTM2Mjc3MTIgLTE2NTM1Nzc3ODIgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4 MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGVyZSBhcmUgbXkgdGhvdWdodHM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpT eW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGdyb3Vw IG9yIGFueSBvdGhlciBJb1QgZ3JvdXAgc2hvdWxkIG5vdCBjb21lIHVwIHdpdGggdGhlaXIgb3du IGFsZ29yaXRobSByZWNvbW1lbmRhdGlvbnMuIFJlYXNvbjogd2UgYWxyZWFkeSBoYXZlIGEgZ3Jv dXAgd29ya2luZyBvbiB0aGVzZSByZWNvbW1lbmRhdGlvbnMNCiAtIENGUkc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0 OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIG5vIG5lZWQgdG8gdGFsayBh Ym91dCBuZXcgYWxnb3JpdGhtcyByZWNvbW1lbmRhdGlvbnMuIFJlYXNvbjogdGhlIHJlY29tbWVu ZGF0aW9ucyBoYXZlIGFscmVhZHkgYmVlbiBtYWRlIGJ5IHRoZSBDRlJHIGFuZCB0aGUgVExTIDEu MyBzcGVjDQogbGlzdHMgdGhlbS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGUgcGFjZSBvZiBzd2l0Y2hpbmcgdG8gbmV3IGNyeXB0byBhbGdvcml0aG0gc2Vl bXMgdG8gYmUgbXVjaCBzbG93ZXIgaW4gdGhlIElvVCB3b3JsZCAoZm9yIHRoZSBkaXNjdXNzZWQg cmVhc29ucykuIEkgZmVlbCB0aGVyZSBpcyB2ZXJ5IGxpdHRsZSBtb3N0DQogb2YgdXMgY2FuIGRv IHRvIGluZmx1ZW5jZSB0aGUgcGFjZS4gUmVhc29uOiB2ZXJ5IGZldyBmb2xrcyB3b3JrIG9uIGlt cGxlbWVudGF0aW9ucyBvZiBjcnlwdG8gYWxnb3JpdGhtcyBmb3IgSW9UIGRldmljZXMuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVu ZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNpYW88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGFubmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpl a3JAcnRmbS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDcgSnVuZSAyMDE4IDIyOjIxPGJyPg0K PGI+VG86PC9iPiBNaWNoYWVsIFJpY2hhcmRzb248YnI+DQo8Yj5DYzo8L2I+IEhhbm5lcyBUc2No b2ZlbmlnOyBhY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBY2VdIEhvdyB0 byBzcGVjaWZ5IERUTFMgTVRJIGluIENPQVAtRVNUPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRCSCwgSSdtIG5vdCBhIGZhbiBvZiBTSE9VTEQmIzQzOywgZXRj LiwgYW5kIHRoZXkncmUgcHJldHR5IGFsaWVuIHRvIFRMUywgc28geW91IHNob3VsZCBqdXN0IHVz ZSB3b3JkcyBpZiB5b3Ugd2FudCB0byBjb252ZXkgdGhlc2UgcG9pbnRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoYXQgc2FpZCwg SSBkb24ndCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgb2JqZWN0aXZlIGhlcmU6IHdlJ3JlIGdlbmVy YWxseSBtb3ZpbmcgdG93YXJkcyB0aGUgQ0ZSRyBjdXJ2ZXMsIHNvIHdoYXQncyB0aGUgcmVhc29u aW5nIGZvciB0aGUgUDI1NiBNVVNUIGFuZCB3aHkgZG8geW91IHRoaW5rIHRoYXQgd2lsbCBjaGFu Z2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFRodSwgSnVuIDcsIDIwMTggYXQgMTA6NDEgQU0sIE1pY2hhZWwgUmljaGFyZHNv biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EiIHRhcmdldD0i X2JsYW5rIj5tY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCkhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hv ZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyB3aHkgZG9uJ3QgeW91IGp1c3QgcmVmZXJlbmNlIDxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTI1IiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzkyNTwvYT4/PGJyPg0KPGJyPg0KSWdu b3JhbmNlIDotKTxicj4NClRoYW5rIHlvdSwgSSB0aGluayB0aGF0IHdlIHdpbGwgcmVmZXJlbmNl IGl0IHRoZW47PGJyPg0KPGJyPg0KU2VjdGlvbiA0LjQgaW5jbHVkZXM6PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF0IHRoZSB0aW1lIG9mIHdyaXRpbmcsIHRoZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWNvbW1lbmRlZCBjdXJ2ZSBpcyBzZWNwMjU2 cjEsIGFuZCB0aGUgdXNlIG9mIHVuY29tcHJlc3NlZCBwb2ludHM8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZm9sbG93cyB0aGUgcmVjb21tZW5kYXRpb24gaW4gQ29BUC4mbmJzcDsg Tm90ZSB0aGF0IHN0YW5kYXJkaXphdGlvbiBmb3I8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgQ3VydmUyNTUxOSAoZm9yIEVDREhFKSBpcyBvbmdvaW5nIChzZWUgW1JGQzc3NDhdKSwg YW5kIHN1cHBvcnQgZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoaXMgY3Vy dmUgd2lsbCBsaWtlbHkgYmUgcmVxdWlyZWQgaW4gdGhlIGZ1dHVyZS48YnI+DQo8YnI+DQp3aGlj aCBpcyB3aGF0IHdlIHdhbnQgdG8gc2F5IGFueXdheS48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0i aW0iPiZuYnNwOyAmbmJzcDsgJmd0OyBJIGFtIG5vdCBhIGJpZyBmYW4gb2YgbWFraW5nIGFsbCBz b3J0cyBvZiBkaWZmZXJlbnQgY3J5cHRvPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jm5i c3A7ICZuYnNwOyAmZ3Q7IHJlY29tbWVuZGF0aW9ucyBpbiBvdXIgc3BlY3MgdGhhdCBkaWZmZXIg c2xpZ2h0bHkuIDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPi0tIDxicj4NCl0mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TmV2ZXIg dGVsbCBtZSB0aGUgb2RkcyEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgaXB2NiBtZXNoIG5ldHdvcmtzIFsgPGJyPg0KXSZuYnNw OyAmbmJzcDtNaWNoYWVsIFJpY2hhcmRzb24sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IG5ldHdvcmsgYXJjaGl0ZWN0Jm5ic3A7IFsgPGJyPg0K XSZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOm1jckBzYW5kZWxtYW4uY2EiPm1j ckBzYW5kZWxtYW4uY2E8L2E+Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuc2FuZGVsbWFuLmNh LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5zYW5kZWxtYW4uY2EvPC9hPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwO3J1Ynkgb24gcmFpbHMmbmJzcDsgJm5i c3A7IFsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86QWNlQGlldGYub3JnIj5BY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwN CiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5 b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM5PR0801MB2097054338CC03563649549FFA7B0AM5PR0801MB2097_-- From nobody Tue Jun 12 06:46:07 2018 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 3577E130EF2 for ; Tue, 12 Jun 2018 06:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7UOtyRp11shU for ; Tue, 12 Jun 2018 06:45:59 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.41]) (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 3225B130E27 for ; Tue, 12 Jun 2018 06:45:59 -0700 (PDT) Received: from 1fSjcR-000C9o-TT by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fSjcR-000CB7-U2 for ace@ietf.org; Tue, 12 Jun 2018 06:45:55 -0700 Received: by emcmailer; Tue, 12 Jun 2018 06:45:55 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fSjcR-000C9o-TT for ace@ietf.org; Tue, 12 Jun 2018 06:45:55 -0700 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.1466.3; Tue, 12 Jun 2018 15:45:54 +0200 To: "ace@ietf.org" From: Ludwig Seitz Message-ID: <7c372c17-9aea-a302-c71a-ef8335266583@ri.se> Date: Tue, 12 Jun 2018 15:45:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: [Ace] ACE hackathon project at IETF 102 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 13:46:04 -0000 Hello ACE, I just wanted to announce that Jim and I will host a hackathon project about the work in ACE at IETF 102 (https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon). Please get in touch if you are interested to contribute or have suggestions. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue Jun 12 08:11:01 2018 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 BB604130FA8 for ; Tue, 12 Jun 2018 08:10:52 -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 N0WXNsDbkYtx for ; Tue, 12 Jun 2018 08:10:46 -0700 (PDT) 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 860A2130E54 for ; Tue, 12 Jun 2018 08:10:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3BAC520090 for ; Tue, 12 Jun 2018 11:24:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6C18F31C3; Tue, 12 Jun 2018 11:07:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 69F1231BA for ; Tue, 12 Jun 2018 11:07:45 -0400 (EDT) From: Michael Richardson To: ace@ietf.org In-Reply-To: <9BEB6564-6096-46A2-B38A-81234D6ECEE3@tzi.org> References: <13635.1528327933@localhost> <9BEB6564-6096-46A2-B38A-81234D6ECEE3@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] How to specify DTLS MTI in COAP-EST X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 15:10:58 -0000 --=-=-= Content-Type: text/plain We have written: + + As per section 3.3 and section 4.4, the + mandatory cipher suite for DTLS in EST-coaps is + TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in , + and the the curve secp256r1 MUST + be supported ; this curve is equivalent to the + NIST P-256 curve. Crypto agility is important, and the + recommendations in section 4.4 and any + updates to RFC7925 concerning Curve25519 and other CFRG curves also applies. https://github.com/SanKumar2015/EST-coaps/commit/94812c98492b6a6b0440155025357fa0b58ca017?diff=split We had a discussion about whether section 4.2 (PSK) and 4.3 (RPK) also applies, and in general they do, but we don't understand the use cases that would result in that usage. (Is it PSK, or EAP-SIM for for instance?) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWx/hvoCLcPvd0N1lAQJTxQgAmEoP+j9LxrsQJHg8Rj0wkSbv1mVlho9v 7cu+0w1wKK34G5nwLJ/SYkxgumzQQWZ6NjccdCz6+BxFBWQZq4aaOuGzdeiIUkRk V7DpIoXCEF4JYIMbrTGjm44+pBFLcZMV579qifHMrGwqNLIKzx1rApoqyIwMWdEd HHMYc0QmaDgoCDWyUGR9dUQKbyh2qQjCHVi437s7i4HQ3Mkd0S4RZYJN1sedsSB9 nnVE5LHcKzz6PkeiGnMAGaePUDDzaKsVMYRfkBuZTKbIRVGhZMWly7YXNBBttvhI cnRbAilTZmEQcTqdYGcwXsSONxceR1WOfic+fon7zmjy/T9W3HUPYw== =NQ2a -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 14 05:09:08 2018 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 3EB821292F1 for ; Thu, 14 Jun 2018 05:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 BV1rBkZy60gZ for ; Thu, 14 Jun 2018 05:09:03 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 0E8D4126F72 for ; Thu, 14 Jun 2018 05:09:03 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id i18-v6so5451909qtp.12 for ; Thu, 14 Jun 2018 05:09:03 -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=ZPa7ZkOIhesX7ZywlahztJbqW5inDdcHYJcyvHlAaZU=; b=dhPJ3k/xd58CTcQNZks+HUJWCP+2aBHb45XFEYhKx3rhvQpWakx/IxREeoPAafkFK0 68In6ldXDBVmVOlt2iKJekUUbm7Q3jSLHCU0HM93zsfjsch/sOBnUzdY6STZS+O1HGjm 0bivodmjQiObvKGL3aTlkvQNHoYACqTnMJY5MLELCTG9iZrAB1mtuA7flhjdyxkcmKqj x9rRESqr1gThFWVT7tnynpp/qg1yPASSAZSQTo1X2jQOAhljm9+kYY4id9eZz/ILhxjA kAp2QgzZz7PMU0kCnhEeHUKnbsVBOJqhm96rA8MOjcE6334naLLJmIwVHHOtFhVAE0Zr 6WnA== 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=ZPa7ZkOIhesX7ZywlahztJbqW5inDdcHYJcyvHlAaZU=; b=WftMBzuAE0+8QFi3F4Mf3YVz2PMep0Qj9V7h+yoex8BpZ2GGN1R8agKiZ7cqqpqSJe jUi0XbCVkbX6IjR3A4zdpEXonQa/6ioVJgXP9nlwvA8U73YriS9YZ89m5AR+mkURG2mN G7fI1gElaUaAE79sZ64MRIyPIclep6xs61ymUqcl2RQ/T390xIAPCia6zFxHvNN5EMXo XiariaOifXmNAO8tT1Ot5g8zvtSCFCWkfyItAe7x5DzwQ+DRqxnsB9vbt6SMnVvZ+zoF kiliecuOsIFEsjJvjivtmptGcXu+F+KgAzezLyYlYqeUf75OtdXmzFdqY68UcNdBOvyt AQgA== X-Gm-Message-State: APt69E0fXFIDq1YhuHiOS56OdGb1bhqTItwaWmIFGbzJzSS1Oty3JiFg gJTSuGRHHkatvNjBpLvkZuT+OkxdFj/lPo0upUA= X-Google-Smtp-Source: ADUXVKLPAR2k4TlPChsPS/vIC3Hb/4Ny5K8dg5OZ6vOaG3G4lW22QQruLGPlKYA60Nv6kGuq102plVCWHlGL1gTecxo= X-Received: by 2002:a0c:98d1:: with SMTP id g17-v6mr1951334qvd.27.1528978142023; Thu, 14 Jun 2018 05:09:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a37:d199:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 05:09:01 -0700 (PDT) In-Reply-To: <99638740-7df6-c646-29bf-a3b295213396@ri.se> References: <99638740-7df6-c646-29bf-a3b295213396@ri.se> From: Cigdem Sengul Date: Thu, 14 Jun 2018 13:09:01 +0100 Message-ID: To: Ludwig Seitz Cc: "ace@ietf.org" , Anthony Kirby , Paul Fremantle Content-Type: multipart/alternative; boundary="0000000000000654ef056e98f731" Archived-At: Subject: Re: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 12:09:07 -0000 --0000000000000654ef056e98f731 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Ludwig, Again thank you for your comments. We are going through them and making several revisions to our draft. We want to discuss two of your comments further: (1) Our text: =E2=80=9Dand the client is authorized to obtain a token for t= he indicated audience (e.g., topics) and scopes (e.g., publish/subscribe permissions)" Your comment: Note that the audience claim is typically used to identify the RS (so in this case the MQTT broker), while the scope is intended to identify both the resource (=3Dtopic) and the actions (=3Dpublish, subscrib= e). See this for how OAuth scopes are typically used: https://www.brandur.org/oauth-scope Our response: According to the draft-IETF-ace-oauth-authz-12, the audience of an access token can be a specific resource or one or many resource servers. So, we considered three ways to structure our tokens, given that a token can hold multiple scopes but only a single audience : (1) aud: RS scopes: underscore separated keywords representing _, e.g., "publish_valve2012/temperature", "subscribe_/foo/+/bar", "subscribe_$SYS/#" (2) aud: resource, i.e., a topic in MQTT context scopes: permissions, i.e., publish and/or subscribe keywords (3) aud: permission, i.e., publish or subscribe scope: topics (i.e., resources), e.g., topic1 topic2 topic3 We think Options (1) and (2) fit the current text in the ace-oauth draft, especially, when we consider this example: { "grant_type" : "client_credentials", "client_id" : "myclient", "client_secret" : "mysecret234", "aud" : "valve424", "scope" : "read", "cnf" : { "kid" : b64'6kg0dXJM13U' } If using option (1), we can choose to leave this as an "application specific convention". On the other hand, it could be useful to have this defined, because MQTT only allows publish & subscribe, and there are rules for the MQTT topic string. This would make ACE-savvy MQTT clients & servers generally more compatible/interoperable. Based on our option (2), these would be in MQTT - =E2=80=9Caud=E2=80=9D: = =E2=80=9Cvalve424=E2=80=9D, =E2=80=9Cscope=E2=80=9D: =E2=80=9Csubscribe=E2=80=9D Note that, the multipl= e tokens trade-off we mention in our draft still exists for the core=E2=80=99s valve example too. This token= does not help with reading =E2=80=9Cvalve425=E2=80=9D. Option (3) is more left-field proposition and does not align with the rest of the core draft. Though, it does have an efficiency advantage that a single token can permit access to multiple topics. Based on the ace-oauth draft, the first two options for token structure should be acceptable. We want to list both to avoid being too prescriptive about scope structures (as the option (1) dictates). (2) Your comment: An example of how the CONNECT message could look like would be good. We think we need a bit of clarification about what kind of an example you have in mind. Our draft has a figure 2 that explains the different field an MQTT Connect packet will have. We could add an example in hex (MQTT being binary) but it wouldn't be as easy to read as the HTTP example. Thanks, =E2=80=94Cigdem & Anthony --0000000000000654ef056e98f731 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Ludwig,

Again thank you for your comments.We are going throu= gh them and making several revisions to our draft.

We want to discuss two of your comments further:<= br style=3D"font-weight:normal;text-decoration:none;color:rgb(0,0,0);font-f= amily:Tahoma,Geneva,sans-serif;font-size:13.3333px">
(1) Our text: =E2=80=9Dand the client i= s authorized to obtain a token for the indicated
=C2=A0=C2=A0 audience (e.g., topics)= and scopes (e.g., publish/subscribe
=C2=A0=C2=A0 permissions)"

Your comment: Note that the audience claim is t= ypically used to identify the RS (so in this case the MQTT broker), while t= he scope is intended to identify both the resource (=3Dtopic) and the actio= ns (=3Dpublish, subscribe).
See this for how OAuth scopes are typically used:<= br style=3D"font-weight:normal;text-decoration:none;color:rgb(0,0,0);font-f= amily:Tahoma,Geneva,sans-serif;font-size:13.3333px">https://www.brandu= r.org/oauth-scope
<= br style=3D"font-weight:normal;text-decoration:none;color:rgb(0,0,0);font-f= amily:Tahoma,Geneva,sans-serif;font-size:13.3333px">Our response:
According to = the draft-IETF-ace-oauth-authz-12, the audience of an access token can be a specific res= ource or one or many resource servers.

So, we considered three ways to str= ucture our tokens,=C2=A0given that a tok= en can hold multiple scopes but only a single audience=C2=A0:
(1)=C2=A0aud: RS

=C2=A0=C2=A0=C2=A0=C2=A0 scopes= :=C2=A0underscore=C2=A0separated keywords representing=C2=A0<permission>_<topic>, e.g.,=C2=A0"publish_valve2012/temperatur= e", "subscribe_/foo/+/bar", "subscribe_$SYS/#"=C2=A0

(2) aud: resource, i.e., a topic in MQTT context

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 scopes: permissions, i.e., publish and/or subscribe keywords

(3)=C2=A0= aud: permission, i.e., publish or subscribe
scope: topics (i.e., = resources), e.g., topic1 topic2 topic3


We think Options (1) and (2)=C2=A0 fit th= e current text in the=C2=A0ace-oauth<= span class=3D"gmail-Apple-converted-space">=C2=A0draft, especially, = when we consider this example:
{
=C2=A0=C2=A0=C2=A0=C2=A0 "grant_type" : "client= _credentials",
=C2=A0=C2=A0=C2=A0=C2=A0 "client_id" : "myclient&q= uot;,
=C2= =A0=C2=A0=C2=A0=C2=A0 "client_secret" : "mysecret234",<= /span>
=C2=A0=C2= =A0=C2=A0=C2=A0 "aud" : "valve424",
=C2=A0=C2=A0=C2=A0=C2=A0 &quo= t;scope" : "read",
=C2=A0=C2=A0=C2=A0=C2=A0 "cnf" : {=
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "kid" : b64'6kg0dXJM13U'
=C2=A0=C2=A0=C2=A0= =C2=A0 }

If using option (1), we can choo= se to leave this as an "application specific convention".=C2=A0 O= n the other hand, it could be useful to have this=C2=A0defined, because MQT= T only allows publish & subscribe, and there are rules for the MQTT top= ic string.=C2=A0 This would make ACE-savvy MQTT clients & servers gener= ally more=C2=A0compatible/interoperable.

Based on our option (2), these would be in MQTT - =E2=80=9Ca= ud=E2=80=9D: =E2=80=9Cvalve424=E2=80=9D, =E2=80=9Cscope=E2=80=9D: = =E2=80=9Csubscribe=E2=80=9D Note that, the multiple tokens trade-off we men= tion in our draft still exists for the core=E2=80=99s valve example too. Th= is token does not help with reading =E2=80=9Cvalve425=E2=80=9D.

O= ption (3)=C2=A0is more left-= field proposition and does not align with the rest of the core draft. Thoug= h, it does=C2=A0<= span style=3D"font-weight:normal;text-decoration:none;font-family:Tahoma,Ge= neva,sans-serif;font-size:13.3333px">have=C2=A0an effi= ciency advantage that a single token can permit access to multiple topics.<= span class=3D"gmail-Apple-converted-space" style=3D"">=C2=A0<= /font>

Based on the ace-oauth draft, th= e first two options for token structure should be acceptable. We want to li= st both to avoid being too prescriptive about scope structures (as the opti= on (1) dictates).
(2)

Your comment: An example of how the CONNEC= T message could look like would be good.

We think we need a bit of clarification about what kind of an = example you have in mind. Our draft has a figure 2 that explains the differ= ent field an MQTT Connect packet will have. We could add an example in hex = (MQTT being binary)=C2=A0=C2=A0but it=C2=A0wouldn't be a= s easy to read as the HTTP example.=C2=A0


Thanks,
=E2=80=94Cigdem & An= thony
--0000000000000654ef056e98f731-- From nobody Fri Jun 15 06:07:49 2018 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 EED8F1292F1 for ; Fri, 15 Jun 2018 06:07:47 -0700 (PDT) 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 03fX6mhZ7cfK for ; Fri, 15 Jun 2018 06:07:44 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.37]) (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 866F7130E3F for ; Fri, 15 Jun 2018 06:07:44 -0700 (PDT) Received: from 1fToS5-000Yuv-VW by out10d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fToS6-000Ywr-U2; Fri, 15 Jun 2018 06:07:42 -0700 Received: by emcmailer; Fri, 15 Jun 2018 06:07:42 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fToS5-000Yuv-VW; Fri, 15 Jun 2018 06:07:41 -0700 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.1466.3; Fri, 15 Jun 2018 15:07:41 +0200 To: Cigdem Sengul CC: "ace@ietf.org" , Anthony Kirby , Paul Fremantle References: <99638740-7df6-c646-29bf-a3b295213396@ri.se> From: Ludwig Seitz Message-ID: <5b1f40ed-4df1-29ef-f911-05b8fc0168dc@ri.se> Date: Fri, 15 Jun 2018 15:07:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 13:07:48 -0000 On 2018-06-14 14:09, Cigdem Sengul wrote: > Hello Ludwig, > > Again thank you for your comments. > We are going through them and making several revisions to our draft. > > We want to discuss two of your comments further: > > (1) Our text: ”and the client is authorized to obtain a token for the > indicated >    audience (e.g., topics) and scopes (e.g., publish/subscribe >    permissions)" > > Your comment: Note that the audience claim is typically used to identify > the RS (so in this case the MQTT broker), while the scope is intended to > identify both the resource (=topic) and the actions (=publish, subscribe). > See this for how OAuth scopes are typically used: > https://www.brandur.org/oauth-scope > > Our response: > According to the draft-IETF-ace-oauth-authz-12, the audience of an > access token can be a specific resource or one or many resource servers. > > So, we considered three ways to structure our tokens,given that a token > can hold multiple scopes but only a single audience : > > (1) aud: RS > >      scopes: underscoreseparated keywords > representing_, e.g.,"publish_valve2012/temperature", > "subscribe_/foo/+/bar", "subscribe_$SYS/#" > > (2) aud: resource, i.e., a topic in MQTT context > >       scopes: permissions, i.e., publish and/or subscribe keywords > > (3) aud: permission, i.e., publish or subscribe > scope: topics (i.e., resources), e.g., topic1 topic2 topic3 > > > We think Options (1) and (2)  fit the current text in > the ace-oauthdraft, especially, when we consider this example: > { >      "grant_type" : "client_credentials", >      "client_id" : "myclient", >      "client_secret" : "mysecret234", >      "aud" : "valve424", >      "scope" : "read", >      "cnf" : { >        "kid" : b64'6kg0dXJM13U' >      } > > If using option (1), we can choose to leave this as an "application > specific convention".  On the other hand, it could be useful to have > this defined, because MQTT only allows publish & subscribe, and there > are rules for the MQTT topic string.  This would make ACE-savvy MQTT > clients & servers generally more compatible/interoperable. > > Based on our option (2), these would be in MQTT - “aud”: “valve424”, > “scope”: “subscribe” Note that, the multiple tokens trade-off we mention > in our draft still exists for the core’s valve example too. This token > does not help with reading “valve425”. > > > Option (3)is more left-field proposition and does not align with the > rest of the core draft. Though, it doeshavean efficiency advantage that > a single token can permit access to multiple topics. > > Based on the ace-oauth draft, the first two options for token structure > should be acceptable. We want to list both to avoid being too > prescriptive about scope structures (as the option (1) dictates). > Note that 'the "aud" value is an array of case- sensitive strings' (RFC7519 section 4.1.3), while scope is a "... list of space-delimited, case-sensitive strings." (RFC6749 section 3.3), so you could authorize access to several topics with different permissions in a single token with all of the approaches you define above. Option 3 is clearly far off from the intended use of aud (' the "aud" (audience) claim identifies the recipients that the JWT is intended for.' ) In option 2 how do you avoid the use of an access token at a different resource broker? (For clarification: Say you have resource broker A and B who both serve similarly named topics, but in entirely different locations, and who happen to use the same AS.) > (2) > > Your comment: An example of how the CONNECT message could look like > would be good. > > We think we need a bit of clarification about what kind of an example > you have in mind. Our draft has a figure 2 that explains the different > field an MQTT Connect packet will have. We could add an example in hex > (MQTT being binary)  but it wouldn't be as easy to read as the HTTP example. > Perhaps hex-code with explanations under the different parts of it as in: 45FC 481A F56B 1234 A527 Header Parameter1 Parameter2 Payload /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Fri Jun 15 06:38:45 2018 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 89E90130ED6 for ; Fri, 15 Jun 2018 06:38:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 470zt1odV1tb for ; Fri, 15 Jun 2018 06:38:41 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 F23D2130ED2 for ; Fri, 15 Jun 2018 06:38:40 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id j80-v6so5581050qke.9 for ; Fri, 15 Jun 2018 06:38:40 -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=JYLKfzjdkfXNKfyutZrwG6jatDfSvTvEpqLHTGWyaos=; b=VYDDflrulkn4JzwTVn1vOtYGVGxUFMyZL6dyAbbLgN+Rs5/yKdolVqL/BslHVJGDn/ pVQK5Ue/S9D7zjymDVJiAJFp39gorsbnotVHpqLK6bQAEy6gmEnCoaM1sJkRSZHEFVC+ z6LBp+kZ1G4owdAGt/oCqKfeJQMGEE9uDArCqlU2f0Q4XuWC2iENS0XSJ5yXC7Usp3J8 1JmhVttSP0WHjDK6KbGTI62RW+JrrzCJEtjlAIC3ixvmCu/hvWWUcOYYnDtICZYWe8lV D+NpTXiMRRWm+1h6f5rhalIsfiSe9YK3x64jKzsaWXYtxn0AAS5xykwmmqr3tn8KsKVv B8WQ== 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=JYLKfzjdkfXNKfyutZrwG6jatDfSvTvEpqLHTGWyaos=; b=pD79pmyGDGNWmjmLshCTQLjaXzXj5ngTqzrxtrZZa0Baun0woZFAyZsixR1chot0YF 8Fj/7ajXsTYe71G0cABToR8ts6NuQDXcZFjcpTtYM+o2WAlUpD/7nfXqlCphRaQ993Kz nArxIZ6LD5wB/hWzF4mgR/WwH1oKRY4rNdCkAkjWGrZ+A0ijdiMmO5ercHAIDIgqkuSc CK1LIdVj9ezFo7jEugOXfB42WQu7b1QqMnwZWzkstj+8lxCcqh1SxKVBhFvcNj8cdHdG xfSdpGlp+ZoK7kB9kssX9tKvsr+4H99t8KEpOjURRZhIaxpw0qtgbi1vCbReP/wG/Lzm uvPw== X-Gm-Message-State: APt69E1FEAG97EGbd/1OnZ6WjSA8bpprNgwwaebE9k2RXxBHC4BjDqRH CaIVdN6vNTlLNwCb1NqvyJySoT0cQLSZLdW6uqM= X-Google-Smtp-Source: ADUXVKK7wvwKgCBIfqkmIeqYngC+2oAOW0K2Oos1wpg2F3CQubJyrc5wHBnyzZnGaKAIEEmyAEgfnk/+NkXvKyjHJ98= X-Received: by 2002:a37:5607:: with SMTP id k7-v6mr1315238qkb.342.1529069920165; Fri, 15 Jun 2018 06:38:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a37:d199:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 06:38:39 -0700 (PDT) In-Reply-To: <5b1f40ed-4df1-29ef-f911-05b8fc0168dc@ri.se> References: <99638740-7df6-c646-29bf-a3b295213396@ri.se> <5b1f40ed-4df1-29ef-f911-05b8fc0168dc@ri.se> From: Cigdem Sengul Date: Fri, 15 Jun 2018 14:38:39 +0100 Message-ID: To: Ludwig Seitz , ace@ietf.org Cc: Anthony Kirby , Paul Fremantle Content-Type: multipart/alternative; boundary="0000000000006da3e3056eae5582" Archived-At: Subject: Re: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 13:38:44 -0000 --0000000000006da3e3056eae5582 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for clarifications Ludwig, True, aud can be an array. We typically avoided this, hence, the omission. For the case (2) to be used, there would be a single RS assumption indeed. This should be clearly said when we are proposing the option 2. Thanks for your response, --Cigdem On Fri, Jun 15, 2018 at 2:07 PM, Ludwig Seitz wrote: > On 2018-06-14 14:09, Cigdem Sengul wrote: > >> Hello Ludwig, >> >> Again thank you for your comments. >> We are going through them and making several revisions to our draft. >> >> We want to discuss two of your comments further: >> >> (1) Our text: =E2=80=9Dand the client is authorized to obtain a token fo= r the >> indicated >> audience (e.g., topics) and scopes (e.g., publish/subscribe >> permissions)" >> >> Your comment: Note that the audience claim is typically used to identify >> the RS (so in this case the MQTT broker), while the scope is intended to >> identify both the resource (=3Dtopic) and the actions (=3Dpublish, subsc= ribe). >> See this for how OAuth scopes are typically used: >> https://www.brandur.org/oauth-scope >> >> Our response: >> According to the draft-IETF-ace-oauth-authz-12, the audience of an acces= s >> token can be a specific resource or one or many resource servers. >> >> So, we considered three ways to structure our tokens,given that a token >> can hold multiple scopes but only a single audience : >> >> (1) aud: RS >> >> scopes: underscoreseparated keywords representing_, >> e.g.,"publish_valve2012/temperature", "subscribe_/foo/+/bar", >> "subscribe_$SYS/#" >> >> (2) aud: resource, i.e., a topic in MQTT context >> >> scopes: permissions, i.e., publish and/or subscribe keywords >> >> (3) aud: permission, i.e., publish or subscribe >> scope: topics (i.e., resources), e.g., topic1 topic2 topic3 >> >> >> We think Options (1) and (2) fit the current text in the ace-oauthdraft= , >> especially, when we consider this example: >> { >> "grant_type" : "client_credentials", >> "client_id" : "myclient", >> "client_secret" : "mysecret234", >> "aud" : "valve424", >> "scope" : "read", >> "cnf" : { >> "kid" : b64'6kg0dXJM13U' >> } >> >> If using option (1), we can choose to leave this as an "application >> specific convention". On the other hand, it could be useful to have >> this defined, because MQTT only allows publish & subscribe, and there ar= e >> rules for the MQTT topic string. This would make ACE-savvy MQTT clients= & >> servers generally more compatible/interoperable. >> >> Based on our option (2), these would be in MQTT - =E2=80=9Caud=E2=80=9D:= =E2=80=9Cvalve424=E2=80=9D, >> =E2=80=9Cscope=E2=80=9D: =E2=80=9Csubscribe=E2=80=9D Note that, the mult= iple tokens trade-off we mention in >> our draft still exists for the core=E2=80=99s valve example too. This to= ken does >> not help with reading =E2=80=9Cvalve425=E2=80=9D. >> >> >> Option (3)is more left-field proposition and does not align with the res= t >> of the core draft. Though, it doeshavean efficiency advantage that a sin= gle >> token can permit access to multiple topics. >> >> Based on the ace-oauth draft, the first two options for token structure >> should be acceptable. We want to list both to avoid being too prescripti= ve >> about scope structures (as the option (1) dictates). >> >> > Note that 'the "aud" value is an array of case- > sensitive strings' (RFC7519 section 4.1.3), while scope is a "... list > of space-delimited, case-sensitive strings." (RFC6749 section 3.3), so yo= u > could authorize access to several topics with different permissions in a > single token with all of the approaches you define above. > > Option 3 is clearly far off from the intended use of aud > (' the "aud" (audience) claim identifies the recipients that the JWT is > intended for.' ) > > In option 2 how do you avoid the use of an access token at a different > resource broker? > (For clarification: Say you have resource broker A and B who both serve > similarly named topics, but in entirely different locations, and who happ= en > to use the same AS.) > > > (2) >> >> Your comment: An example of how the CONNECT message could look like woul= d >> be good. >> >> We think we need a bit of clarification about what kind of an example yo= u >> have in mind. Our draft has a figure 2 that explains the different field= an >> MQTT Connect packet will have. We could add an example in hex (MQTT bein= g >> binary) but it wouldn't be as easy to read as the HTTP example. >> >> > > Perhaps hex-code with explanations under the different parts of it as in: > > 45FC 481A F56B 1234 A527 > Header Parameter1 Parameter2 Payload > > /Ludwig > > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > --0000000000006da3e3056eae5582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0for clarifications Ludwig,=C2=A0

True,=C2=A0=C2=A0aud=C2=A0can be an array. We typically av= oided this, hence, the omission.=C2=A0

For the cas= e (2) to be used, there would be a single RS assumption indeed. This should= be clearly said when we are proposing the option 2.


Thanks for your response,
--Cigdem=C2=A0
<= div class=3D"gmail_extra">
On Fri, Jun 15, 20= 18 at 2:07 PM, Ludwig Seitz <ludwig.seitz@ri.se> wrote:
=
On 2018-06-14 14:09, Cigdem= Sengul wrote:
Hello Ludwig,

Again thank you for your comments.
We are going through them and making several revisions to our draft.

We want to discuss two of your comments further:

(1) Our text: =E2=80=9Dand the client is authorized to obtain a token for t= he indicated
=C2=A0=C2=A0=C2=A0 audience (e.g., topics) and scopes (e.g., publish/subscr= ibe
=C2=A0=C2=A0=C2=A0 permissions)"

Your comment: Note that the audience claim is typically used to identify th= e RS (so in this case the MQTT broker), while the scope is intended to iden= tify both the resource (=3Dtopic) and the actions (=3Dpublish, subscribe).<= br> See this for how OAuth scopes are typically used:
https://www.brandur.org/oauth-scope

Our response:
According to the draft-IETF-ace-oauth-authz-12, the audience of an access t= oken can be a specific resource or one or many resource servers.

 So, we considered three ways to structure our tokens,given that a token can= hold multiple scopes but only a single audience=C2=A0:

(1) aud: RS

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scopes:=C2=A0underscoreseparated keywords re= presenting<permission>_<topic>, e.g.,"publish_valve20= 12/temperature", "subscribe_/foo/+/bar", "subscrib= e_$SYS/#"

(2) aud: resource, i.e., a topic in MQTT context

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scopes: permissions, i.e., publish and= /or subscribe keywords

(3) aud: permission, i.e., publish or subscribe
scope: topics (i.e., resources), e.g., topic1 topic2 topic3


 We think Options (1) and (2)=C2=A0 fit the current text in the=C2=A0ace-oau= thdraft, especially, when we consider this example:
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "grant_type" : "client_creden= tials",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "client_id" : "myclient"= ,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "client_secret" : "mysecret23= 4",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "aud" : "valve424",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "scope" : "read",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "cnf" : {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "kid" : b64'6kg0dX= JM13U'
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

If using option (1), we can choose to leave this as an "application sp= ecific convention".=C2=A0 On the other hand, it could be useful to hav= e this=C2=A0defined, because MQTT only allows publish & subscribe, and = there are rules for the MQTT topic string.=C2=A0 This would make ACE-savvy = MQTT clients & servers generally more compatible/interoperable.

Based on our option (2), these would be in MQTT - =E2=80=9Caud=E2=80=9D: = =E2=80=9Cvalve424=E2=80=9D, =E2=80=9Cscope=E2=80=9D: =E2=80=9Csubscribe=E2= =80=9D Note that, the multiple tokens trade-off we mention in our draft sti= ll exists for the core=E2=80=99s valve example too. This token does not hel= p with reading =E2=80=9Cvalve425=E2=80=9D.


 Option (3)is more left-field proposition and does not align with the rest o= f the core draft. Though, it doeshavean efficiency advantage that a single = token can permit access to multiple topics.

Based on the ace-oauth draft, the first two options for token structure sho= uld be acceptable. We want to list both to avoid being too prescriptive abo= ut scope structures (as the option (1) dictates).


Note that 'the "aud" value is an array of case-
=C2=A0 =C2=A0sensitive strings' (RFC7519 section 4.1.3), while scope is= a "... list of space-delimited, case-sensitive strings." (RFC674= 9 section 3.3), so you could authorize access to several topics with differ= ent permissions in a single token with all of the approaches you define abo= ve.

Option 3 is clearly far off from the intended use of aud
(' the "aud" (audience) claim identifies the recipients that = the JWT is
=C2=A0 =C2=A0intended for.' )

In option 2 how do you avoid the use of an access token at a different reso= urce broker?
(For clarification: Say you have resource broker A and B who both serve sim= ilarly named topics, but in entirely different locations, and who happen to= use the same AS.)


(2)

Your comment: An example of how the CONNECT message could look like would b= e good.

We think we need a bit of clarification about what kind of an example you h= ave in mind. Our draft has a figure 2 that explains the different field an = MQTT Connect packet will have. We could add an example in hex (MQTT being b= inary) =C2=A0but it=C2=A0wouldn't be as easy to read as the HTTP exampl= e.



 Perhaps hex-code with explanations under the different parts of it as in:
45FC=C2=A0 =C2=A0 481A=C2=A0 =C2=A0 =C2=A0 =C2=A0 F56B=C2=A0 =C2=A0 =C2=A0 = =C2=A0 1234=C2=A0 A527
Header=C2=A0 Parameter1=C2=A0 Parameter2=C2=A0 Payload

/Ludwig



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

--0000000000006da3e3056eae5582-- From nobody Sat Jun 16 06:34:38 2018 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 A7DAD130E43; Sat, 16 Jun 2018 06:34:36 -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 XF0dZeYVGIMU; Sat, 16 Jun 2018 06:34:33 -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 5BD5B130E3E; Sat, 16 Jun 2018 06:34:33 -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 w5GDYTh3016843; Sat, 16 Jun 2018 15:34:29 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 417JHT4FM3zDXmH; Sat, 16 Jun 2018 15:34:29 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 550848867.3362-46253f92ae822c5022ffbc08a3f25e61 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sat, 16 Jun 2018 15:34:28 +0200 Message-Id: To: ace , Core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF102: DRAFT AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 16 Jun 2018 13:34:37 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF102. Remember that there is still quite some potential for changes. ACE vs. DISPATCH seems to become a common occurrance; at this rate, I'll probably never see a DISPATCH meeting again. CBOR vs. 6LO is maybe just a personal problem for me, throwing in TEEP on top is a bit weird, though. 6TISCH vs. SUIT is probably painful for the few individuals who care about security in both. All times are EDT (UTC-0400). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) (Centre Ville) -- Sun 1800-2000: HotRFC (Viger) MONDAY, July 16, 2018 0930-1200 Morning Session I Duluth ART dispatch Dispatch WG - Joint with ARTAREA Laurier INT 6man IPv6 Maintenance WG Place du Canada RTG detnet Deterministic Networking WG Viger SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Viger INT ipwave IP Wireless Access in Vehicular = Environments WG Place du Canada SEC tls Transport Layer Security WG 1550-1750 Afternoon Session II Viger ART *** core Constrained RESTful Environments WG Place du Canada INT intarea Internet Area Working Group WG 1810-1940 Afternoon Session III Laurier GEN rfcplusplus The label "RFC" BOF TUESDAY, July 17, 2018 0930-1200 Morning Session I Place du Canada IRTF irtfopen IRTF Open Meeting St-Paul/St-Cath RTG babel Babel routing protocol WG Duluth RTG *** roll Routing Over Low power and Lossy = networks WG 1330-1530 Afternoon Session I Duluth ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Van Horne INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Laurier RTG rtgarea Routing Area Open Meeting Viger SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1820 Afternoon Session II Place du Canada ART httpbis Hypertext Transfer Protocol WG Viger IRTF cfrg Crypto Forum - 1720 - 1820 Centre Ville IRTF icnrg Information-Centric Networking Van Horne SEC acme Automated Certificate Management = Environment WG - 1720 - 1820 Van Horne SEC oauth Web Authorization Protocol WG - 1550 - = 1720 Duluth TSV taps Transport Services WG WEDNESDAY, July 18, 2018 0930-1200 Morning Session I Van Horne OPS anima Autonomic Networking Integrated Model = and Approach WG St-Paul/St-Cath RTG bier Bit Indexed Explicit Replication WG Duluth SEC secdispatch Security Dispatch WG Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Laurier ART httpbis Hypertext Transfer Protocol WG Van Horne INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** suit Software Updates for Internet of Things = WG 1520-1650 Afternoon Session II Centre Ville INT homenet Home Networking WG Viger TSV tsvarea Transport Area Open Meeting THURSDAY, July 19, 2018 0930-1200 Morning Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Viger SEC mls Messaging Layer Security WG Van Horne SEC oauth Web Authorization Protocol WG - 0930 - = 1100 1330-1530 Afternoon Session I Centre Ville OPS v6ops IPv6 Operations WG Viger RTG rift Routing In Fat Trees WG Place du Canada SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Viger IRTF*** t2trg Thing-to-Thing Duluth OPS driu DNS Resolver Identification and Use BOF Centre Ville TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Van Horne ART *** core Constrained RESTful Environments WG Place du Canada SEC tls Transport Layer Security WG Centre Ville TSV tsvwg Transport Area Working Group WG FRIDAY, July 20, 2018 0930-1130 Morning Session I Duluth IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Place du Canada OPS v6ops IPv6 Operations WG St-Paul/St-Cath TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1150-1320 Afternoon Session I Duluth INT *** lwig Light-Weight Implementation Guidance WG Laurier IRTF panrg Path Aware Networking Proposed RG Centre Ville SEC tokbind Token Binding WG From nobody Sat Jun 16 16:03:31 2018 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 2EE06130E59; Sat, 16 Jun 2018 16:03:29 -0700 (PDT) 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 MhKjzwuUj7t6; Sat, 16 Jun 2018 16:03:27 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E8A13113D; Sat, 16 Jun 2018 16:03:26 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 16 Jun 2018 16:00:04 -0700 From: Jim Schaad To: CC: References: <359EC4B99E040048A7131E0F4E113AFC014C3B7AED@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C3B7AED@marathon> Date: Sat, 16 Jun 2018 16:02:59 -0700 Message-ID: <004f01d405c6$2dc73340$895599c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKOtyUn4c9iuoOiLaWua0SXHdP956LuHWHg X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 16 Jun 2018 23:03:30 -0000 We have seen a number of messages on this document, but we have not yet seen an updated draft that addresses all of these issues. When should we expect a new version. It would have been nice to have had two published before Montreal but that does not seem likely at this point. Jim > -----Original Message----- > From: Ace On Behalf Of Roman Danyliw > Sent: Wednesday, May 16, 2018 6:18 AM > To: ace@ietf.org > Subject: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession- > 02 > > Hello! > > A reminder to the WG, draft-ietf-ace-cwt-proof-of-possession is in WGLC. > Please send feedback to the mailing list by Wednesday, May 23. > > Thanks, > Roman and Jim > > > -----Original Message----- > > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Roman Danyliw > > Sent: Tuesday, May 08, 2018 6:19 PM > > To: ace@ietf.org > > Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > > > Hello! > > > > Consistent with the feedback from the editor team at the London > > meeting, we are starting a working group last call (WGLC) for the > > "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)" draft: > > > > ** draft-ietf-ace-cwt-proof-of-possession-02 > > ** > > https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02 > > > > Please send comments to the mailing list -- feedback on issues or > > needed changes; as well as endorsements that this draft is ready. > > > > This WGLC will end on Wednesday, May 23, 2018. > > > > Thanks, > > Roman and Jim > > > > _______________________________________________ > > 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 From nobody Mon Jun 18 05:02:43 2018 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 D531E130EA5; Mon, 18 Jun 2018 05:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 CVCWJLmlwWel; Mon, 18 Jun 2018 05:02:36 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0053.outbound.protection.outlook.com [104.47.2.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 C2DB4130E96; Mon, 18 Jun 2018 05:02:35 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=X8V7LKW0vJ4tNGbUNKxfwTFSRPTv8bciVKX5hcM3N7s=; b=VTuF6MnGfJSMl0j6veSsX1LR6uaCRh6lNQrZUxWAgCbqkEaBoD2YXUmqlM3toLHQYoywr+uY4z8Uzu4sF4g7d8WKeglnx7rOxsYDVi1qOD/LRsRvHOBbT6h5HM1ZNYoHX8Ha6KAliD/dcIdUPpx0jLs2X5eoeQg1U5gElHcWkLI= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2077.eurprd08.prod.outlook.com (10.173.74.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.14; Mon, 18 Jun 2018 12:02:32 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 12:02:32 +0000 From: Hannes Tschofenig To: Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" CC: "ace@ietf.org" Thread-Topic: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdPtGEH4pwi+TQ+ERcWMpVROGZpXzgYrelqAAE14V/A= Date: Mon, 18 Jun 2018 12:02:32 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC014C3B7AED@marathon> <004f01d405c6$2dc73340$895599c0$@augustcellars.com> In-Reply-To: <004f01d405c6$2dc73340$895599c0$@augustcellars.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: [83.175.123.202] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2077; 7:QKwgP53p9EOT3tR+6pTTbZ1xwKs8+rTfKtiAysMPIUV799RBh+zbue2hCAIbxor7P1uSSmDjlH25WYDAEFnFpXUHE7/G1Rciquiz1KO35mIx8iwB5s+eX7270ssXE6W09QDUG6yhFsoQ1Binwi02ItHL9t+ML2xqgrC0oDEUhOCLbI5Pn6wZ8s1yvQUkwem+Q1oY4WFbUYq54zZul3UnqZr0wKAN4IvMS1hChndPcnffMRctKqR5pR6++wXQKz6s x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3e973b52-867b-4448-84b9-08d5d5135fab x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2077; x-ms-traffictypediagnostic: VI1PR0801MB2077: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB2077; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2077; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(376002)(366004)(346002)(396003)(189003)(199004)(12213003)(40434004)(34654002)(13464003)(966005)(33656002)(6246003)(74316002)(59450400001)(97736004)(8936002)(476003)(6506007)(11346002)(446003)(8676002)(14454004)(86362001)(81156014)(81166006)(486006)(102836004)(53546011)(99286004)(6306002)(53936002)(6116002)(3846002)(55016002)(7696005)(9686003)(478600001)(2900100001)(72206003)(105586002)(106356001)(76176011)(25786009)(2906002)(316002)(5660300001)(305945005)(3660700001)(5250100002)(2501003)(26005)(7736002)(6436002)(4326008)(66066001)(5890100001)(3280700002)(110136005)(186003)(229853002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2077; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: mHH3rJhElmY1lQ/UpbbG6sM66KIB7L+kgRyj/noc6KVbc/SVpODed63K0M+sktPYn9tV8aizELg/KyEAdP70glEUE1DwK5bRg31X+z4/OUCy+OOcW2QFgFyKGHolGIuAXvxFOpyVOMxWV3NmpnYRUorOGphKCUbeDFWS0SL9H7YFCNDWt+YjvVxpwWvAS9jGPMk1Xd/hCkg7tKpJUiQ3lwlE3rCE9cSkyHwIJRX8oUO/abi/NK7vTkJL4ElfD4e+9xiYWl2yjg3PmVP386b/NhWqle3t1wRZBZUaOpT4VJ4xD3PdzQPYGADGhOMN1wSJ6/3bi7yZiiiKTVkFmod4sQ== 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: 3e973b52-867b-4448-84b9-08d5d5135fab X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 12:02:32.7312 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2077 Archived-At: Subject: Re: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 12:02:41 -0000 Hi Jim, I have made changes to the draft based on your review and the updated versi= on of the document can be found at https://github.com/cwt-cnf/i-d/pull/13 However, I am not sure we have consensus on the changes. Ciao Hannes -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: 17 June 2018 01:03 To: draft-ietf-ace-cwt-proof-of-possession@ietf.org Cc: ace@ietf.org Subject: RE: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possessi= on-02 We have seen a number of messages on this document, but we have not yet see= n an updated draft that addresses all of these issues. When should we expect a new version. It would have been nice to have had two published before Montreal but that does not seem likely at this point. Jim > -----Original Message----- > From: Ace On Behalf Of Roman Danyliw > Sent: Wednesday, May 16, 2018 6:18 AM > To: ace@ietf.org > Subject: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession= - > 02 > > Hello! > > A reminder to the WG, draft-ietf-ace-cwt-proof-of-possession is in WGLC. > Please send feedback to the mailing list by Wednesday, May 23. > > Thanks, > Roman and Jim > > > -----Original Message----- > > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Roman Danyliw > > Sent: Tuesday, May 08, 2018 6:19 PM > > To: ace@ietf.org > > Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > > > Hello! > > > > Consistent with the feedback from the editor team at the London > > meeting, we are starting a working group last call (WGLC) for the > > "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)" draft: > > > > ** draft-ietf-ace-cwt-proof-of-possession-02 > > ** > > https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02 > > > > Please send comments to the mailing list -- feedback on issues or > > needed changes; as well as endorsements that this draft is ready. > > > > This WGLC will end on Wednesday, May 23, 2018. > > > > Thanks, > > Roman and Jim > > > > _______________________________________________ > > 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 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 Jun 18 09:02:24 2018 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 0118C130DF5; Mon, 18 Jun 2018 09:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 k8dTg6sr4o3n; Mon, 18 Jun 2018 09:02:17 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700125.outbound.protection.outlook.com [40.107.70.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DC3130EED; Mon, 18 Jun 2018 09:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YacP/fcTcT6yq3mibxGA9z4PhYOQybvRYQCYrQ/EzTE=; b=aWAIXAA+58ND6DyXv/y1hn7cprAz+HPmXfYhje19VM2FpcpcDu5X7G4BybtDpKJxGUnaWLCcnsYAwalCFsL2FmlVYv5NWDc0AIiU5suPDe1/zA5Fds2VHkKh0X64C/mVjl7M1B8B5dVYP5dNIUkJEMFUAZCSydOhAF1+S+Sej/A= Received: from SN6PR00MB0301.namprd00.prod.outlook.com (52.132.117.155) by SN6PR00MB0384.namprd00.prod.outlook.com (52.132.118.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.919.0; Mon, 18 Jun 2018 16:01:54 +0000 Received: from SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::1835:2a6b:5366:6133]) by SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::1835:2a6b:5366:6133%5]) with mapi id 15.20.0917.000; Mon, 18 Jun 2018 16:01:53 +0000 From: Mike Jones To: Hannes Tschofenig , Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" CC: "ace@ietf.org" Thread-Topic: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdPtGEH4pwi+TQ+ERcWMpVROGZpXzgYrelqAAE14V/AACE9iUQ== Date: Mon, 18 Jun 2018 16:01:53 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC014C3B7AED@marathon> <004f01d405c6$2dc73340$895599c0$@augustcellars.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0384; 7:oo51Vm/0fBvEE/y7AM4Qc0nxQhtOT9StEJT/x8j5Rqvo8Nast+fb91VbQFKXkP5NriPhwEa+tDHw6AeoN8mqsjOCZIL+TRGWnaTopxaQ/xGwDGxTEyWzt68ve+DlT1Z1N0rUIj8Sg1jy+vBS3C8TE6wA7k6hVp//cJvjN2YYG9+hsB6ufvs57DAkNJy4Bg0LKkHBgYZPtCX3gBjdnSKDEYquGeUYORJypk+AXEHwU7S+BDh2ttHY5vBaolah7eK8 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fe702c88-fad0-4e4e-c194-08d5d534cf6e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:SN6PR00MB0384; x-ms-traffictypediagnostic: SN6PR00MB0384: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(166708455590820)(100405760836317); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0384; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0384; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39380400002)(39860400002)(366004)(376002)(199004)(189003)(12213003)(13464003)(40434004)(34654002)(606006)(2900100001)(3280700002)(10090500001)(2906002)(3660700001)(106356001)(9686003)(105586002)(236005)(6606003)(5660300001)(6306002)(54896002)(97736004)(66066001)(33656002)(478600001)(72206003)(10290500003)(86362001)(8990500004)(966005)(14454004)(68736007)(86612001)(11346002)(476003)(6116002)(486006)(3846002)(19627405001)(446003)(6436002)(229853002)(316002)(110136005)(53936002)(99286004)(22452003)(5890100001)(2501003)(53546011)(6506007)(6246003)(5250100002)(59450400001)(102836004)(25786009)(4326008)(74316002)(81166006)(7736002)(186003)(7696005)(81156014)(76176011)(55016002)(8676002)(26005)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0384; H:SN6PR00MB0301.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5/KUhkDcOgnPrcKu3F1kxl5M57H3WQfM6Vsu94/CpTm292S2nz7I9L5oTFCJXWniy0d3r6W8p1jf+VWU/CBWOQgJ9C85pAvUL45RV0nC/07+I36ZfdTOwWv5UQRJrpNP7eXjIjNmxzJHr+pMfrZ7os5fGTiQBrIRGgnbgLqkSTGO7d/KZSKd9+s+2WwQPiAwfmkK1vQm22oLny6A3n0x4j+aDS1hjAM1/DlSCa+l1GcIvZEnMYP6893TZaPz3AAVEAobztflII+8EQwozYZp6FjfaxKjuAC+037u2OcU9XiAxb5vqmfz1GkUMo6rb3DjugRzt/LCr4dDdql/T8Sqqw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR00MB03014AD20C008FDCFEEA6300F5710SN6PR00MB0301namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe702c88-fad0-4e4e-c194-08d5d534cf6e X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 16:01:53.6260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0384 Archived-At: Subject: Re: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 16:02:22 -0000 --_000_SN6PR00MB03014AD20C008FDCFEEA6300F5710SN6PR00MB0301namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proposed change to allow multiple PoP keys in a single "cnf" element in= troduces unnecessary syntactic and semantic ambiguity. It also breaks the s= emantic equivalence with RFC 7800. Hannes, you're right that there's not co= nsensus to do this. Please see my review of your pull request at https://github.com/cwt-cnf/i-d/pull/13/files/b81205b292acb393592f2e803a4767= 0e46928c73. Thanks, -- Mike ________________________________ From: Hannes Tschofenig Sent: Monday, June 18, 2018 5:02:32 AM To: Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.org Cc: ace@ietf.org Subject: RE: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possessi= on-02 Hi Jim, I have made changes to the draft based on your review and the updated versi= on of the document can be found at https://github.com/cwt-cnf/i-d/pull/13 However, I am not sure we have consensus on the changes. Ciao Hannes -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: 17 June 2018 01:03 To: draft-ietf-ace-cwt-proof-of-possession@ietf.org Cc: ace@ietf.org Subject: RE: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possessi= on-02 We have seen a number of messages on this document, but we have not yet see= n an updated draft that addresses all of these issues. When should we expect a new version. It would have been nice to have had two published before Montreal but that does not seem likely at this point. Jim > -----Original Message----- > From: Ace On Behalf Of Roman Danyliw > Sent: Wednesday, May 16, 2018 6:18 AM > To: ace@ietf.org > Subject: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession= - > 02 > > Hello! > > A reminder to the WG, draft-ietf-ace-cwt-proof-of-possession is in WGLC. > Please send feedback to the mailing list by Wednesday, May 23. > > Thanks, > Roman and Jim > > > -----Original Message----- > > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Roman Danyliw > > Sent: Tuesday, May 08, 2018 6:19 PM > > To: ace@ietf.org > > Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > > > Hello! > > > > Consistent with the feedback from the editor team at the London > > meeting, we are starting a working group last call (WGLC) for the > > "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)" draft: > > > > ** draft-ietf-ace-cwt-proof-of-possession-02 > > ** > > https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02 > > > > Please send comments to the mailing list -- feedback on issues or > > needed changes; as well as endorsements that this draft is ready. > > > > This WGLC will end on Wednesday, May 23, 2018. > > > > Thanks, > > Roman and Jim > > > > _______________________________________________ > > 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 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_SN6PR00MB03014AD20C008FDCFEEA6300F5710SN6PR00MB0301namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The proposed change to allow mult= iple PoP keys in a single "cnf" element introduces unnecessary syntactic and semantic ambiguity. It also breaks the semantic = equivalence with RFC 7800. Hannes, you're right that there's not consensus = to do this.

=

= Please see my review of your pull request at

https://github.com/cw= t-cnf/i-d/pull/13/files/b81205b292acb393592f2e803a47670e46928c73.


Thanks,

-- Mike

From: Hannes Tschofenig <= ;Hannes.Tschofenig@arm.com>
Sent: Monday, June 18, 2018 5:02:32 AM
To: Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.org
Cc: ace@ietf.org
Subject: RE: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-p= ossession-02
 
Hi Jim,

I have made changes to the draft based on your review and the updated versi= on of the document can be found at https://github.com/cwt-c= nf/i-d/pull/13
However, I am not sure we have consensus on the changes.

Ciao
Hannes

-----Original Message-----
From: Jim Schaad [mailto:ietf@aug= ustcellars.com]
Sent: 17 June 2018 01:03
To: draft-ietf-ace-cwt-proof-of-possession@ietf.org
Cc: ace@ietf.org
Subject: RE: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possessi= on-02

We have seen a number of messages on this document, but we have not yet see= n
an updated draft that addresses all of these issues.  When should we e= xpect
a new version.  It would have been nice to have had two published befo= re
Montreal but that does not seem likely at this point.

Jim


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Roman Danyliw
> Sent: Wednesday, May 16, 2018 6:18 AM
> To: ace@ietf.org
> Subject: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possess= ion-
> 02
>
> Hello!
>
> A reminder to the WG, draft-ietf-ace-cwt-proof-of-possession is in WGL= C.
> Please send feedback to the mailing list by Wednesday, May 23.
>
> Thanks,
> Roman and Jim
>
> > -----Original Message-----
> > From: Ace [mailto:ace-bou= nces@ietf.org] On Behalf Of Roman Danyliw
> > Sent: Tuesday, May 08, 2018 6:19 PM
> > To: ace@ietf.org
> > Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02<= br> > >
> > Hello!
> >
> > Consistent with the feedback from the editor team at the London > > meeting, we are starting a working group last call (WGLC) for the=
> > "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs= )" draft:
> >
> > ** draft-ietf-ace-cwt-proof-of-possession-02
> > **
> > https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02 > >
> > Please send comments to the mailing list -- feedback on issues or=
> > needed changes; as well as endorsements that this draft is ready.=
> >
> > This WGLC will end on Wednesday, May 23, 2018.
> >
> > Thanks,
> > Roman and Jim
> >
> > _______________________________________________
> > 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

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_SN6PR00MB03014AD20C008FDCFEEA6300F5710SN6PR00MB0301namp_-- From nobody Tue Jun 19 02:40:30 2018 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 EB8751310DB; Tue, 19 Jun 2018 02:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 AG9lH4dXupFb; Tue, 19 Jun 2018 02:40:19 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0072.outbound.protection.outlook.com [104.47.1.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282BD1310CA; Tue, 19 Jun 2018 02:40:18 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=3sDlZYXaKT95tL5lrv0nT4IBMYS6P5W8AlZwZjhRSA4=; b=pXvQNZc6b9rsU84ZUaesvcj2G9GwwcpKfd+FIDDxfG78gQrlTS3lMBy7wdGlXbgvNq7AH9LZbmNtj9dkLAjsaMOGN9qaldPSoGAagVGid4Yhc89UNEIaVJEXA5kdGXGs57DQFB4RiO2DJJOoWhGZE2Z8ZT91k5kEZZiG8bgk9lU= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1679.eurprd08.prod.outlook.com (10.168.66.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Tue, 19 Jun 2018 09:40:16 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 09:40:16 +0000 From: Hannes Tschofenig To: "consultancy@vanderstok.org" , Carsten Bormann CC: core , "ace@ietf.org" Thread-Topic: [core] [Ace] Early media-type registration for EST over CoAP Thread-Index: AdPsKhcQ9FbwjekBT1SYYUyoYtG38gAB1S+AAAdDwHAALHlyAAAAGtIAAZoVoYAAAOWDAAAAmhQABRCXITA= Date: Tue, 19 Jun 2018 09:40:16 +0000 Message-ID: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> 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: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1679; 7:cXHernTLZT2ibvSBHGoaxDGh95O6Pa2Rah1l598s/Oj7OwxNY0fik2u33DTpNqDUjIDEHF92g9cIOtUHqEE8WrRikf6Ab7Zgt0HBlUhXDGGtiolqfdv6B5tMjGcurEynHYU7AN1VryrO2qaXmXja/N9Rz83clnHef1WCjXlS3dKpHv9+puvHlRBhD6/WtmxExxDa1ogyY8mYWXrTeduV0DledVXSuU5J2dTdIV1TEiZciyPfGd6pAAiaMK1KkDb6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e309dd92-d94c-49c2-8012-08d5d5c8a9e4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1679; x-ms-traffictypediagnostic: VI1PR0801MB1679: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1679; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1679; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39860400002)(366004)(39380400002)(40434004)(13464003)(53754006)(57704003)(189003)(199004)(86362001)(4326008)(229853002)(68736007)(5660300001)(6116002)(3846002)(186003)(25786009)(102836004)(33656002)(26005)(8676002)(2900100001)(6246003)(106356001)(6436002)(53936002)(81166006)(8936002)(81156014)(105586002)(446003)(3280700002)(2906002)(3660700001)(476003)(7736002)(66066001)(9686003)(2501003)(6306002)(11346002)(486006)(74316002)(316002)(14454004)(5250100002)(5890100001)(305945005)(561944003)(97736004)(54906003)(110136005)(55016002)(99286004)(7696005)(53546011)(966005)(478600001)(93886005)(72206003)(59450400001)(76176011)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1679; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9dE1k/aPcBmlTSoKBvP7urijZ+qzN3zePoqOBPNiU8PhMAT40yWM2/ckz8XtXXTOsLr/ZdfWDdnE/xcvZ1SJCBy0U0e8nUeWBeJNFDgswte0HoF75JZ6vCtptucIt2vUZhvtN+6pjLDOHIlK8J79hJ9Xc0a1vrN2HRO9/9mMnyPg8ncfdtsQDil1jQN6O6ryMoFlInbXVAMr1KlRdbSEXIVnDQxME4sYXQSItLLKDAutmIOgdrQVAhkm20e6zIMPWJckNVw88iD3T/IH/FLInfE+OvjUKRnsIsDElTHA1xi2MB7WR4zTR0QX0GOO7eJMwd/lJOPiutOICKuXMa0jIQ== 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: e309dd92-d94c-49c2-8012-08d5d5c8a9e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 09:40:16.1811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1679 Archived-At: Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 09:40:24 -0000 UGV0ZXIsDQoNCkRpZCB0aGlzIHJlZ2lzdHJhdGlvbiBhdHRlbXB0IGdvdCBjb25jbHVkZWQ/DQoN CkNpYW8NCkhhbm5lcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGV0ZXIg dmFuIGRlciBTdG9rIFttYWlsdG86c3Rva2NvbnNAeHM0YWxsLm5sXQ0KU2VudDogMjQgTWF5IDIw MTggMTU6NTUNClRvOiBDYXJzdGVuIEJvcm1hbm4NCkNjOiBIYW5uZXMgVHNjaG9mZW5pZzsgY29y ZTsgYWNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFtBY2VdIEVhcmx5IG1lZGlhLXR5 cGUgcmVnaXN0cmF0aW9uIGZvciBFU1Qgb3ZlciBDb0FQDQoNCk9rLCBJIHdpbGwgcmFpc2UgdGhl IGV4cGVydHMgdG8tbW9ycm93Lg0KDQpQZXRlcg0KDQpDYXJzdGVuIEJvcm1hbm4gc2NocmVlZiBv cCAyMDE4LTA1LTI0IDE2OjM3Og0KPiBPbiBNYXkgMjQsIDIwMTgsIGF0IDE2OjE1LCBIYW5uZXMg VHNjaG9mZW5pZw0KPiA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4gd3JvdGU6DQo+Pg0KPj4g SGkgYWxsLA0KPj4NCj4+IFRyeWluZyB0byBmaW5hbGl6ZSB0aGlzIGRpc2N1c3Npb246IENvdWxk IHdlIGRvIGFuIGVhcmx5IHJlZ2lzdHJ5IG9mDQo+PiB0aGUgQ29udGVudC1Gb3JtYXQgbnVtYmVy cz8NCj4NCj4gWWVzLg0KPg0KPj4gRnJvbSB0aGUgZGlzY3Vzc2lvbiBzbyBmYXIgSSBiZWxpZXZl IHdlIGNvbmNsdWRlZCB0aGF0IHRoZSBjaGFyc2V0IGlzDQo+PiB1dGYtOA0KPg0KPiBXaGF0IGNo YXJzZXQ/ICBJIHRob3VnaHQgd2UgZG9u4oCZdCBoYXZlIHBhcmFtZXRlcnMgKHNlZSBiZWxvdyku DQo+DQo+PiBhbmQgdGhhdCB0aGVyZSBhcmUgbm8gcGFyYW1ldGVycy4gSXMgdGhhdCBjb3JyZWN0 Pw0KPg0KPiBUaGF0IGlzIG15IHVuZGVyc3RhbmRpbmcgc28gZmFyLCBidXQgdGhlIHBvaW50IG9m IG1lIGFza2luZyB0aGUNCj4gcXVlc3Rpb24gd2FzIHRvIGFzayB0aGUgYWN0dWFsIGV4cGVydHMg YWJvdXQgdGhlc2UgbWVkaWEgdHlwZXMuICBEaWQNCj4gd2UgZ2V0IHRoYXQgaW5wdXQ/DQo+DQo+ IE5leHQgc3RlcDogbWFrZSBhIHByb3Bvc2FsIGFuZCByYWlzZSB0aGlzIG9uIGNvcmUtcGFyYW1l dGVyc0BpZXRmLm9yZw0KPiBzbyB3ZSBnZXQgdGhlIG5lZWRlZCBpbnB1dCBmcm9tIHRoZSBkZXNp Z25hdGVkIGV4cGVydC4NCj4NCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPg0KPg0KPj4NCj4+IENpYW8N Cj4+IEhhbm5lcw0KPj4NCj4+IEZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHpp Lm9yZ10NCj4+IFNlbnQ6IDE2IE1heSAyMDE4IDEyOjMwDQo+PiBUbzogSGFubmVzIFRzY2hvZmVu aWcNCj4+IENjOiBhY2VAaWV0Zi5vcmc7IGNvcmUNCj4+IFN1YmplY3Q6IFJlOiBbQWNlXSBFYXJs eSBtZWRpYS10eXBlIHJlZ2lzdHJhdGlvbiBmb3IgRVNUIG92ZXIgQ29BUA0KPj4NCj4+IEZvcmdv dCB0byBhZGQgYW5vdGhlciBleGFtcGxlOiB0aGUgY29udGVudC1mb3JtYXQgbnVtYmVycyBmb3Ig Q09TRQ0KPj4gaGF2ZSBwYXJhbWV0ZXJzLg0KPj4NCj4+IFNlbnQgZnJvbSBtb2JpbGUNCj4+DQo+ PiBPbiAxNi4gTWF5IDIwMTgsIGF0IDEyOjI2LCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9y Zz4gd3JvdGU6DQo+Pg0KPj4gSSB3YXMgdGhpbmtpbmcgYWJvdXQgbWVkaWEgdHlwZSBwYXJhbWV0 ZXJzIHN1Y2ggYXMgY2hhcnNldD0idXRmLTgiLg0KPj4gVGhlIFJUIHZhbHVlIG5lZWQgdG8gYmUg cmVnaXN0ZXJlZCBzZXBhcmF0ZWx5LCBidXQgd2UgY2FuIGJlIGEgYml0DQo+PiBsYXp5IGFib3V0 IHRoYXQuDQo+Pg0KPj4gU2VudCBmcm9tIG1vYmlsZQ0KPj4NCj4+IE9uIDE2LiBNYXkgMjAxOCwg YXQgMTI6MTUsIEhhbm5lcyBUc2Nob2ZlbmlnDQo+PiA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bT4gd3JvdGU6DQo+Pg0KPj4gSGkgQ2Fyc3RlbiwNCj4+DQo+PiBZZXMsIEkgYW0gdGFsa2luZyBh Ym91dCB0aGUgQ29udGVudC1Gb3JtYXQgbnVtYmVycyBmb3IgdGhlbS4NCj4+IFdvdWxkIHJ0PSJh Y2UuZXN0IiBiZSB0aGUgcGFyYW1ldGVyIHlvdSBhcmUgdGFsa2luZyBhYm91dD8NCj4+DQo+PiBD aWFvDQo+PiBIYW5uZXMNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJv bTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emkub3JnXQ0KPj4gU2VudDogMTUgTWF5 IDIwMTggMTE6NDUNCj4+IFRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4gQ2M6IGFjZUBpZXRmLm9y ZzsgY29yZQ0KPj4gU3ViamVjdDogUmU6IFtBY2VdIEVhcmx5IG1lZGlhLXR5cGUgcmVnaXN0cmF0 aW9uIGZvciBFU1Qgb3ZlciBDb0FQDQo+Pg0KPj4gT24gTWF5IDE1LCAyMDE4LCBhdCAxMDo1Niwg SGFubmVzIFRzY2hvZmVuaWcNCj4+IDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToN Cj4+DQo+Pg0KPj4gSSBhbSBjdXJpb3VzIHdoZXRoZXIgaXQgd291bGQgYmUgcG9zc2libGUgdG8g YXNrIGZvciBlYXJseSBtZWRpYS10eXBlDQo+PiByZWdpc3RyYXRpb24gb2YgYXQgbGVhc3QgdGhl c2UgdHdvIHR5cGVzOg0KPj4gLSBhcHBsaWNhdGlvbi9wa2NzNy1taW1lDQo+PiAtIGFwcGxpY2F0 aW9uL3BrY3MxMA0KPj4NCj4+IFRoZXJlIGFscmVhZHkgYXJlIHJlZ2lzdGVyZWQuDQo+Pg0KPj4g SSB0aGluayB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgZ2V0dGluZyBDb250ZW50LUZvcm1hdCBudW1i ZXJzIGZvcg0KPj4gdGhlc2U/DQo+PiBEbyB3ZSBuZWVkIGFueSBwYXJhbWV0ZXJzIG9yIGNvbnRl bnQtY29kaW5ncyB3aXRoIHRoYXQ/DQo+Pg0KPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPj4NCj4+IElN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlDQo+PiBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4gcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZQ0KPj4gdGhlIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9y DQo+PiBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo+Pg0K Pj4NCj4+IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlDQo+PiBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZp bGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4gcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZQ0KPj4gdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9y IHN0b3JlIG9yDQo+PiBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5 b3UuDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gQWNlIG1haWxpbmcgbGlzdA0KPj4gQWNlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Tue Jun 19 05:11:45 2018 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 9F278130E75; Tue, 19 Jun 2018 05:11:36 -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 NwMDp8FdgC_W; Tue, 19 Jun 2018 05:11:33 -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 DF8F8130E6A; Tue, 19 Jun 2018 05:11:32 -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 w5JCBREe024611; Tue, 19 Jun 2018 14:11:27 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 4196JH0tt1zDWnx; Tue, 19 Jun 2018 14:11:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 19 Jun 2018 14:11:26 +0200 Cc: peter van der Stok , core , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 551103084.705636-fe66a2a218adc989b79b0fcc7348be9d Content-Transfer-Encoding: quoted-printable Message-Id: <7198364E-F831-423F-8709-D96E152FD888@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 12:11:37 -0000 Since the registry that we are registering into does not fulfill the = preconditions of RFC 7120 Section 2 point (a), I think the next step is = to send the registration to IANA using the protocol parameters form [1]. = The application should reference the I-D as well as the message from = the DE [2] =E2=80=94 there will be another interaction between IANA and = DE and then we should be done. To do so without further friction, the = I-D probably should have been updated to align with [2]. [1]: https://www.iana.org/form/protocol-assignment [2]: = https://www.ietf.org/mail-archive/web/core-parameters/current/msg00024.htm= l Gr=C3=BC=C3=9Fe, Carsten > On Jun 19, 2018, at 11:40, Hannes Tschofenig = wrote: >=20 > Peter, >=20 > Did this registration attempt got concluded? >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: 24 May 2018 15:55 > To: Carsten Bormann > Cc: Hannes Tschofenig; core; ace@ietf.org > Subject: Re: [core] [Ace] Early media-type registration for EST over = CoAP >=20 > Ok, I will raise the experts to-morrow. >=20 > Peter >=20 > Carsten Bormann schreef op 2018-05-24 16:37: >> On May 24, 2018, at 16:15, Hannes Tschofenig >> wrote: >>>=20 >>> Hi all, >>>=20 >>> Trying to finalize this discussion: Could we do an early registry of >>> the Content-Format numbers? >>=20 >> Yes. >>=20 >>> =46rom the discussion so far I believe we concluded that the charset = is >>> utf-8 >>=20 >> What charset? I thought we don=E2=80=99t have parameters (see = below). >>=20 >>> and that there are no parameters. Is that correct? >>=20 >> That is my understanding so far, but the point of me asking the >> question was to ask the actual experts about these media types. Did >> we get that input? >>=20 >> Next step: make a proposal and raise this on core-parameters@ietf.org >> so we get the needed input from the designated expert. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: 16 May 2018 12:30 >>> To: Hannes Tschofenig >>> Cc: ace@ietf.org; core >>> Subject: Re: [Ace] Early media-type registration for EST over CoAP >>>=20 >>> Forgot to add another example: the content-format numbers for COSE >>> have parameters. >>>=20 >>> Sent from mobile >>>=20 >>> On 16. May 2018, at 12:26, Carsten Bormann wrote: >>>=20 >>> I was thinking about media type parameters such as charset=3D"utf-8". >>> The RT value need to be registered separately, but we can be a bit >>> lazy about that. >>>=20 >>> Sent from mobile >>>=20 >>> On 16. May 2018, at 12:15, Hannes Tschofenig >>> wrote: >>>=20 >>> Hi Carsten, >>>=20 >>> Yes, I am talking about the Content-Format numbers for them. >>> Would rt=3D"ace.est" be the parameter you are talking about? >>>=20 >>> Ciao >>> Hannes >>>=20 >>> -----Original Message----- >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: 15 May 2018 11:45 >>> To: Hannes Tschofenig >>> Cc: ace@ietf.org; core >>> Subject: Re: [Ace] Early media-type registration for EST over CoAP >>>=20 >>> On May 15, 2018, at 10:56, Hannes Tschofenig >>> wrote: >>>=20 >>>=20 >>> I am curious whether it would be possible to ask for early = media-type >>> registration of at least these two types: >>> - application/pkcs7-mime >>> - application/pkcs10 >>>=20 >>> There already are registered. >>>=20 >>> I think you are talking about getting Content-Format numbers for >>> these? >>> Do we need any parameters or content-codings with that? >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> 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 >>>=20 >>> 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 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > 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 Tue Jun 19 05:22:49 2018 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 75EBC130EA3; Tue, 19 Jun 2018 05:22:47 -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 3-XqzmORSyZJ; Tue, 19 Jun 2018 05:22:46 -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 C2CF7130E95; Tue, 19 Jun 2018 05:22:45 -0700 (PDT) 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 w5JCMfBQ002853; Tue, 19 Jun 2018 14:22:41 +0200 (CEST) Received: from client-0101.vpn.uni-bremen.de (client-0101.vpn.uni-bremen.de [134.102.107.101]) (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 4196YF31dzzDWp6; Tue, 19 Jun 2018 14:22:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <7198364E-F831-423F-8709-D96E152FD888@tzi.org> Date: Tue, 19 Jun 2018 14:22:40 +0200 Cc: core , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 551103759.141158-68dcec812618ae55160340b2631910a4 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 12:22:48 -0000 On Jun 19, 2018, at 14:11, Carsten Bormann wrote: >=20 > Since the registry that we are registering into does not fulfill the = preconditions of RFC 7120 Section 2 point (a), (Sorry, wasn=E2=80=99t awake enough. If we go for the 256-9999 space, = of course it does. And we probably do.) So we=E2=80=99ll have to follow the process according to Section 3 of = RFC 7120. Starting with point (1) of Section 3.1: 1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and to which document they should be assigned. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 19 07:36:27 2018 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 73EE2131183; Tue, 19 Jun 2018 07:36:21 -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 zpBY3d14PzT1; Tue, 19 Jun 2018 07:36:17 -0700 (PDT) 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 07293131172; Tue, 19 Jun 2018 07:36:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0F8C220090; Tue, 19 Jun 2018 10:50:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4DCB11A69; Tue, 19 Jun 2018 10:33:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B38B1A68; Tue, 19 Jun 2018 10:33:15 -0400 (EDT) From: Michael Richardson To: core , "ace\@ietf.org" In-Reply-To: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 14:36:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: >> >> Since the registry that we are registering into does not fulfill the >> preconditions of RFC 7120 Section 2 point (a), > (Sorry, wasn=E2=80=99t awake enough. If we go for the 256-9999 space= , of > course it does. And we probably do.) yes, we were perfectly happy with that space. > So we=E2=80=99ll have to follow the process according to Section 3 of= RFC 7120. > Starting with point (1) of Section 3.1: > 1. The authors (editors) of the document submit a request for ear= ly > allocation to the Working Group chairs, specifying which code points > require early allocation and to which document they should be assigne= d. I thought ACE co-chairs already gave consent, but looking in the archives, I see that this isn't actually so. Jim? Roman? DO YOU CONSENT? We have already had some round trips and document changes thanks to Klaus H= artke. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWykUKICLcPvd0N1lAQLeOAgAr+zRrSZVWe2OCzACCr8wv6XjZYAsobZY PMBqtFsuILUN0UHVTQ78EakFvPsJAs41cidXoPJZSYiEgtz5nXi7zsljJnOGT27/ jDLVsMDF2Tkr5QSp4Ui8AeUFHX9dmoGMkbxCkiAoccptRZBlDZhKPfO/3+l94zQ/ +2cNz55t3aIDHYXcLhCBbuZIlgN18VQ53l19zc9nwvqzFUp23OzKZGr2UdN7/ZY0 Smtm0XdjTurqKId2EJqJI8AtYqUirUtMztsUhLrz2WJiWenZA24Xlcvn6VT1ca3f GdEzM/YqYIk5RcoIGbEqNmSUQI/4HQjh1fWL7cYjgtHXKexgV/MN+g== =CTJh -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 19 08:25:31 2018 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 D09931311A4; Tue, 19 Jun 2018 08:25:21 -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 ksr5mknGhGVO; Tue, 19 Jun 2018 08:25:18 -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 F42391311AF; Tue, 19 Jun 2018 08:25:16 -0700 (PDT) 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 w5JFPDaA022867; Tue, 19 Jun 2018 17:25:13 +0200 (CEST) Received: from client-0114.vpn.uni-bremen.de (client-0114.vpn.uni-bremen.de [134.102.107.114]) (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 419Bbs329zzDWr0; Tue, 19 Jun 2018 17:25:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <26117.1529418795@localhost> Date: Tue, 19 Jun 2018 17:25:12 +0200 Cc: core , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 551114711.31085-725aed01c4295c1d73f5acc98da3370b Content-Transfer-Encoding: quoted-printable Message-Id: <5300AE6B-7CA6-4D1E-BAA0-61C64233E1B0@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <26117.1529418795@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 15:25:23 -0000 On Jun 19, 2018, at 16:33, Michael Richardson = wrote: >=20 > We have already had some round trips and document changes thanks to = Klaus Hartke. Yes, but the IANA considerations section currently still has multict in = it =E2=80=94 that might confuse IANA. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 19 09:22:11 2018 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 381EA130F76; Tue, 19 Jun 2018 09:22:09 -0700 (PDT) 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 YV9UWN_stx3E; Tue, 19 Jun 2018 09:22:06 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7E9130DE1; Tue, 19 Jun 2018 09:22:06 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Jun 2018 09:19:01 -0700 From: Jim Schaad To: 'Michael Richardson' , 'core' , References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <26117.1529418795@localhost> In-Reply-To: <26117.1529418795@localhost> Date: Tue, 19 Jun 2018 09:21:59 -0700 Message-ID: <01b701d407e9$a78b5dd0$f6a21970$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQG/S+RHVkCkQxegzhC32weTrUzzBwIfwDTTAqVFXzMBqqx8WgLhhBh7AciFkcwCU/daGAI1GHuCAgGCadECFFGudgHA077GAiyGetGj1AuXcA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 16:22:10 -0000 > -----Original Message----- > From: Ace On Behalf Of Michael Richardson > Sent: Tuesday, June 19, 2018 7:33 AM > To: core ; ace@ietf.org > Subject: Re: [Ace] [core] Early media-type registration for EST over = CoAP >=20 >=20 > Carsten Bormann wrote: > > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: > >> > >> Since the registry that we are registering into does not = fulfill the > >> preconditions of RFC 7120 Section 2 point (a), >=20 > > (Sorry, wasn=E2=80=99t awake enough. If we go for the 256-9999 = space, of > > course it does. And we probably do.) >=20 > yes, we were perfectly happy with that space. >=20 > > So we=E2=80=99ll have to follow the process according to Section = 3 of RFC 7120. >=20 > > Starting with point (1) of Section 3.1: >=20 > > 1. The authors (editors) of the document submit a request = for early > > allocation to the Working Group chairs, specifying which code = points > > require early allocation and to which document they should be = assigned. >=20 > I thought ACE co-chairs already gave consent, but looking in the = archives, I > see that this isn't actually so. >=20 > Jim? Roman? DO YOU CONSENT? I do not believe that I have ever seen a formal request directed at me = for this. Jim >=20 > We have already had some round trips and document changes thanks to > Klaus Hartke. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Tue Jun 19 11:05:32 2018 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 0620D1311B8; Tue, 19 Jun 2018 11:05:30 -0700 (PDT) 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 lCzD1Si5XRQF; Tue, 19 Jun 2018 11:05:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E944130DCA; Tue, 19 Jun 2018 11:05:25 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Jun 2018 11:02:20 -0700 From: Jim Schaad To: CC: Date: Tue, 19 Jun 2018 11:05:17 -0700 Message-ID: <01c601d407f8$16621ec0$43265c40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdQGcXKF8YIRrZ4rROuMt4FYvHdJPQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review of draft-ietf-ace-oauth-authz -12 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 18:05:30 -0000 Based on where I currently am, here is another review of the document. 1. In section 4 for Figure one: Is the term "RS Information" your term or an OAuth term. When I see this I think of it as information for not about the RS which I do not believe is the intent. 2. In section 5.1 - I am unclear what the second paragraph is supposed to be doing here. I think that you want state this different. Rather than talking about the "desired resource" you may want to talk about the AS. That would better match the title of the section. 3. In section 5.1 - There is a note in this section that does not seem to be extremely useful. Where is this discussion go on? Is it still going on? I am not even sure if the statement about a common understanding of time is correct? It seems that one can either add or not add the nonce as an RS depending on if you think you understand a common time. 4. In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc. Given the use of POP tokens, what is the reason for this draft and the text about client credential types? (Put it this way. I did not need to implement this for anything yet. Why is it here?) Given 15 different introspection tokens, how do I decide which is the one to present to the AS - enumerate them? 'authorization code' vs 'decode code' grants From nobody Tue Jun 19 23:57:10 2018 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 9BC11131028 for ; Tue, 19 Jun 2018 23:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 qYiJPPHloOcY for ; Tue, 19 Jun 2018 23:57:06 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80087.outbound.protection.outlook.com [40.107.8.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF22A130FBE for ; Tue, 19 Jun 2018 23:57:05 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=2+VR+NQFbjwZbXtGWvk4wIi6M6stuoImvS/lOg+1XPw=; b=T8JGjqvNaw4th4VVp+cm/tCifd5hanfNeN0KNHirv8P3xgz9q2dSDhdUXrEglrkvYdiNZZogGcyUafAV6GLb/7R0ilmSZ3sn/1rZ34yU3/NBEB8nt038LVfkSCxCZvPxtmGRjzI5Jzqy0L79snp5qwLRfTiTfmThG/XgXndAt0w= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1568.eurprd08.prod.outlook.com (10.167.211.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Wed, 20 Jun 2018 06:57:02 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 06:57:02 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: CWT-PoP & Multiple PoP keys Thread-Index: AdQIY2SAG/d3FGSqSlGPkPFJdW2VHQ== Date: Wed, 20 Jun 2018 06:57:02 +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: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1568; 7:QPKS/4SkmOq088iTaNrsY4ebgOluN5V1m/2jTU5Xt8P02YOCq6oi+ZKKkoPdcCm+/O0Lf/GtqyeY+ICAchYqMeG4sVodvGYluLWz0eoRecIsE0llxUzDJUGdVll50HW2dR9dK8VRL3TDc269QhGlbUDWlZ7yenSRgIwsWCcdb64ei8SoO5Tg+0PQmp2ph6cMLmj3OVVUB3Xc8NnbTC/J3gLSlJUlhkERwq1cptR5zeoa4FxKMrossrumB4m6bN2i x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: db0f75bd-5c8a-47f5-b23a-08d5d67b06ef x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1568; x-ms-traffictypediagnostic: VI1PR0801MB1568: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231254)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1568; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1568; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(39860400002)(366004)(376002)(346002)(189003)(199004)(40434004)(6306002)(7736002)(3280700002)(8676002)(1730700003)(9686003)(81156014)(8936002)(53936002)(3660700001)(2900100001)(81166006)(2906002)(790700001)(6116002)(97736004)(3846002)(105586002)(55016002)(2351001)(25786009)(33656002)(54896002)(106356001)(5640700003)(6436002)(2501003)(5660300001)(186003)(86362001)(5890100001)(66066001)(74316002)(9326002)(316002)(486006)(6916009)(72206003)(26005)(5250100002)(99286004)(59450400001)(68736007)(6506007)(14454004)(478600001)(7696005)(476003)(5630700001)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1568; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Q+25k4y9Vm96p9Zvm08qCxlXSFO7FpF7reZ6Uw0I4FXrxbXZl406XQ8vKXLxm5s/Vdd0GY6U9yi2vQ2S1JCiVXHh0RASY+xOur0+mGJA1S9naHcWRThK3iH7PUvQ6kW3uzkjjn3AJLJ82RDlaJJUh0Xvt0fkPS/G2ReKqWIrbDImfLyx1lQcYxhWjKY4SlgX7aMTo6mnrLF5nEOsk87F2VigsymFy42RD9p140vb0uYH8x2SxDFv3uxDaaGKJE7hdgW6xCYdGghkPeHHILKs8fza8nTds8y8x5Dbso+TRqq+/1oxwPuy3kkVKVP1bfv/8Fl2m3O9j4Fj7BRBBMQRtg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211205E0BA138E58D99E485DFA770VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: db0f75bd-5c8a-47f5-b23a-08d5d67b06ef X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 06:57:02.6985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1568 Archived-At: Subject: [Ace] CWT-PoP & Multiple PoP keys X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 06:57:09 -0000 --_000_VI1PR0801MB211205E0BA138E58D99E485DFA770VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I had a chat with Mike about relaxing the CWT-PoP spec to allow multiple Po= P keys in a single CWT token. He is concerned about the departure from RFC 7800 and, after giving it a bi= t more thoughts, I believe there is an issue. Initially, when we started th= e work our promise was that this is really just an alternative encoding of = RFC 7800. With changes like those we are obviously breaking that concept. H= aving multiple keys within a single CWT is a corner case and I am not sure = anymore whether I indeed want to go into that direction. In our implementat= ion we are also not using multiple keys in a single CWT either. 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_VI1PR0801MB211205E0BA138E58D99E485DFA770VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

I had a chat with Mike about relaxing the CWT-PoP sp= ec to allow multiple PoP keys in a single CWT token.

 

He is concerned about the departure from RFC 7800 an= d, after giving it a bit more thoughts, I believe there is an issue. Initia= lly, when we started the work our promise was that this is really just an a= lternative encoding of RFC 7800. With changes like those we are obviously breaking that concept. Having multiple= keys within a single CWT is a corner case and I am not sure anymore whethe= r I indeed want to go into that direction. In our implementation we are als= o not using multiple keys in a single CWT either.

 

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_VI1PR0801MB211205E0BA138E58D99E485DFA770VI1PR0801MB2112_-- From nobody Wed Jun 20 00:14:22 2018 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 C639A130F73 for ; Wed, 20 Jun 2018 00:14:20 -0700 (PDT) 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 p3-zoTbk8ik9 for ; Wed, 20 Jun 2018 00:14:17 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.33]) (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 95E9512D949 for ; Wed, 20 Jun 2018 00:14:17 -0700 (PDT) Received: from 1fVXJl-000alJ-V9 by out10c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fVXJl-000amR-W8 for ace@ietf.org; Wed, 20 Jun 2018 00:14:13 -0700 Received: by emcmailer; Wed, 20 Jun 2018 00:14:13 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fVXJl-000alJ-V9 for ace@ietf.org; Wed, 20 Jun 2018 00:14:13 -0700 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.1466.3; Wed, 20 Jun 2018 09:14:13 +0200 To: References: From: Ludwig Seitz Message-ID: <2e1720cf-ae24-552a-8eff-0fe1aefda46d@ri.se> Date: Wed, 20 Jun 2018 09:14:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.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-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] CWT-PoP & Multiple PoP keys X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 07:14:21 -0000 On 2018-06-20 08:57, Hannes Tschofenig wrote: > Hi Jim, > > I had a chat with Mike about relaxing the CWT-PoP spec to allow multiple > PoP keys in a single CWT token. > > He is concerned about the departure from RFC 7800 and, after giving it a > bit more thoughts, I believe there is an issue. Initially, when we > started the work our promise was that this is really just an alternative > encoding of RFC 7800. With changes like those we are obviously breaking > that concept. Having multiple keys within a single CWT is a corner case > and I am not sure anymore whether I indeed want to go into that > direction. In our implementation we are also not using multiple keys in > a single CWT either. > > Ciao > > Hannes > I agree that having multiple PoP keys in cnf for CWT-PoP seem like overkill. After all this is a draft aimed at constrained environments. I also sympathize with Mike's suggestion to keep CWT-PoP aligned with RFC 7800. /Ludwig > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended Sending confidential email to a public mailing list again Hannes? You are a rebel ;-) -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Jun 20 03:07:16 2018 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 9390F131067; Wed, 20 Jun 2018 03:07:14 -0700 (PDT) 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] 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 rYLTm449xqu4; Wed, 20 Jun 2018 03:07:12 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0151.hostedemail.com [216.40.44.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869EF130DD0; Wed, 20 Jun 2018 03:07:12 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 3A0A2182CF66C; Wed, 20 Jun 2018 10:07:11 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1535:1542:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2528:2553:2559:2566:2570:2682:2685:2693:2703:2827:2859:2895:2909:2933:2937:2939:2942:2945:2947:2951:2954:3022:3148:3352:3622:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4117:4250:4321:4860:5007:6117:6119:6261:7875:7903:8603:9010:9025:9177:10004:10346:10400:11658:12379:12740:13139:13158:13228:13237, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: bikes38_218d813895d54 X-Filterd-Recvd-Size: 6300 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf03.hostedemail.com (Postfix) with ESMTPA; Wed, 20 Jun 2018 10:07:10 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b97923618629a809caeae3594b16be85" Date: Wed, 20 Jun 2018 12:07:10 +0200 From: Peter van der Stok To: Carsten Bormann Cc: Hannes Tschofenig , core , ace@ietf.org, Jim Schaad , rdd@cert.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> Message-ID: <91797cd1747cf05db20d64662306e038@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.129.53] Archived-At: Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 10:07:15 -0000 --=_b97923618629a809caeae3594b16be85 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 HI Carsten, Jim Just to get this clear. We will update the the est-coaps draft by referring to draft-fossati-core-multipart-ct-05 [1] for the wanted early registration of the content formats specified in est-coaps. Once done, we direct a request for early registration of the content-format values to the ACE chairs. Although the corresponding media formats have not been allocated yet for multipart-ct draft, the corresponding content-format numbers can be allocated already. Is that the approved plan? Please confirm or specify the conditions on multipart-ct draft. Many thanks for your understanding, Peter Carsten Bormann schreef op 2018-06-19 14:22: > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: > >> Since the registry that we are registering into does not fulfill the preconditions of RFC 7120 Section 2 point (a), > > (Sorry, wasn't awake enough. If we go for the 256-9999 space, of course it does. And we probably do.) > > So we'll have to follow the process according to Section 3 of RFC 7120. > > Starting with point (1) of Section 3.1: > > 1. The authors (editors) of the document submit a request for early > allocation to the Working Group chairs, specifying which code > points require early allocation and to which document they should > be assigned. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Links: ------ [1] https://datatracker.ietf.org/doc/draft-fossati-core-multipart-ct/ --=_b97923618629a809caeae3594b16be85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Carsten, Jim

Just to get this clear.

We will updat= e the the est-coaps draft by referring to draft-fossati-core-multip= art-ct-05 for the wanted early registration of the content fo= rmats specified in est-coaps.
Once done, we direct a request for early= registration of the content-format values to the ACE chairs.
Although= the corresponding media formats have not been allocated yet for multipart-= ct draft, the corresponding content-format numbers can be allocated already= =2E

Is that the approved plan?

Please confirm or spec= ify the conditions on multipart-ct draft.

Many thanks for your u= nderstanding,

Peter

Carsten Bormann schreef op 2018-06-19 14:22:

= On Jun 19, 2018, at 14:11, Carsten Bormann <cabo@tzi.org> wrote:

Since the registry that we are registering into= does not fulfill the preconditions of RFC 7120 Section 2 point (a),
(Sorry, wasn't awake enough.  If we go for the 256-9999 space, = of course it does.  And we probably do.)

So we'll have to = follow the process according to Section 3 of RFC 7120.

Starting= with point (1) of Section 3.1:

   1.  The = authors (editors) of the document submit a request for early
 &n= bsp;     allocation to the Working Group chairs, s= pecifying which code
       points= require early allocation and to which document they should
 &nb= sp;     be assigned.

Grüße,= Carsten

_______________________________________________
= core mailing list
= core@ietf.org
https://www.ietf.org/mailman/listin= fo/core
--=_b97923618629a809caeae3594b16be85-- From nobody Wed Jun 20 08:48:18 2018 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 8F1F512F1AC for ; Wed, 20 Jun 2018 08:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 FirqUX9LJzDo for ; Wed, 20 Jun 2018 08:48:09 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0116.outbound.protection.outlook.com [104.47.42.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B36D120049 for ; Wed, 20 Jun 2018 08:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cGRI0HFo2LTiUVK2LZCAVOR1fUmRUwrsjGFk5AxNC8Y=; b=Y9NtW8ZitiL+0H6CP7GU4yA0TY4tRMxxu7GVs3At2aasmxzHate/R/0XgTCVMVqqSEL+Ad2a0GVPbjdd3/4VcmseCfiaAoA109Jmpvbglwjb6Ne41A5UjJZaU6dnoXD73Yd/eNHAEGVoVlVthg95GAaksHuAnct7tLOzqtIlzG4= Received: from SN6PR00MB0301.namprd00.prod.outlook.com (52.132.117.155) by SN6PR00MB0334.namprd00.prod.outlook.com (52.132.118.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.921.0; Wed, 20 Jun 2018 15:48:07 +0000 Received: from SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::1835:2a6b:5366:6133]) by SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::1835:2a6b:5366:6133%5]) with mapi id 15.20.0926.000; Wed, 20 Jun 2018 15:48:07 +0000 From: Mike Jones To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] CWT-PoP & Multiple PoP keys Thread-Index: AdQIY2SAG/d3FGSqSlGPkPFJdW2VHQAAuX+AABHr2tA= Date: Wed, 20 Jun 2018 15:48:07 +0000 Message-ID: References: <2e1720cf-ae24-552a-8eff-0fe1aefda46d@ri.se> In-Reply-To: <2e1720cf-ae24-552a-8eff-0fe1aefda46d@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0334; 7:oOW2kS2ugjF8jbD4yAm9QamWjsJNHwJu73xCqQPtL4m12+NMzMBguIv0dzFRSuV4WtNBc1ScJkUIRkro6P+sbwvRy2Ogp89f7cevfYe0Ruhw8/rN7SAuKKMDLXmhEKJi0+NuURgxDSGh0j7da8Pe0Mj1onXNyK1nqbKqqMA2KB/LRHBQYSd9sPnGFcJCVtFQQjqy9C0PcFa/0ztgrLkFUa2WFC6VtGyrePem8zUvkkUvjVnCP7ZbfJkJlzGGaKMB x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 96c99894-1721-4576-d9e5-08d5d6c537d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:SN6PR00MB0334; x-ms-traffictypediagnostic: SN6PR00MB0334: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0334; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0334; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(39380400002)(396003)(366004)(13464003)(189003)(199004)(33656002)(5660300001)(6246003)(8990500004)(476003)(486006)(446003)(186003)(11346002)(66066001)(2900100001)(7696005)(102836004)(97736004)(26005)(76176011)(59450400001)(74316002)(6506007)(53936002)(53546011)(8676002)(81166006)(2906002)(81156014)(3846002)(6116002)(10090500001)(9686003)(229853002)(22452003)(316002)(6436002)(55016002)(99286004)(110136005)(6306002)(68736007)(3280700002)(3660700001)(14454004)(105586002)(2501003)(5250100002)(966005)(86362001)(8936002)(305945005)(5890100001)(10290500003)(25786009)(7736002)(72206003)(478600001)(86612001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0334; H:SN6PR00MB0301.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DyEdlsq8Aqa7r0bggjTT76WZm18LxljQetdSFEyw90iQFX/ir+M1O8g1AIYxrLJy+4X2yyFMWRcu2dyq9mfn3hXcONsGaJbY30CGYvJ59LiQnSTe21AM2Y+AdCwTmdHE8SsWo28lJ5UtpbUW32XI4ibmIkTpxss0VuCQXwOkSNt9g2aKWYuKqSMmcDNhybCdIhOXXVcivquSqha5Fvhkj1ABe+h6ab/5PXXvKqkvZuqSQ6NTgqtSomG8HDklEy/2qGwMyrdspSa8MiG/5u60y4HVUyYbC1pNHBKy5koa8dWU0rf+QgKxvdBWByumqvjsMLv1/R4+udLGNyBgBd274g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96c99894-1721-4576-d9e5-08d5d6c537d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 15:48:07.4447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0334 Archived-At: Subject: Re: [Ace] CWT-PoP & Multiple PoP keys X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 15:48:13 -0000 Good. Having resolved this, I believe we should be in position to do a rel= ease addressing the WGLC comments this week. -- Mike -----Original Message----- From: Ace On Behalf Of Ludwig Seitz Sent: Wednesday, June 20, 2018 12:14 AM To: ace@ietf.org Subject: Re: [Ace] CWT-PoP & Multiple PoP keys On 2018-06-20 08:57, Hannes Tschofenig wrote: > Hi Jim, >=20 > I had a chat with Mike about relaxing the CWT-PoP spec to allow=20 > multiple PoP keys in a single CWT token. >=20 > He is concerned about the departure from RFC 7800 and, after giving it=20 > a bit more thoughts, I believe there is an issue. Initially, when we=20 > started the work our promise was that this is really just an=20 > alternative encoding of RFC 7800. With changes like those we are=20 > obviously breaking that concept. Having multiple keys within a single=20 > CWT is a corner case and I am not sure anymore whether I indeed want=20 > to go into that direction. In our implementation we are also not using=20 > multiple keys in a single CWT either. >=20 > Ciao >=20 > Hannes > I agree that having multiple PoP keys in cnf for CWT-PoP seem like overkill= . After all this is a draft aimed at constrained environments. I also sympathize with Mike's suggestion to keep CWT-PoP aligned with RFC 7= 800. /Ludwig > IMPORTANT NOTICE: The contents of this email and any attachments are=20 > confidential and may also be privileged. If you are not the intended Sending confidential email to a public mailing list again Hannes? You are a= rebel ;-) --=20 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 From nobody Wed Jun 20 09:13:12 2018 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 04FC8130E19; Wed, 20 Jun 2018 09:13:05 -0700 (PDT) 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, 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 TIwqUn-pqi2K; Wed, 20 Jun 2018 09:13:02 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261A8126DBF; Wed, 20 Jun 2018 09:13:02 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Jun 2018 09:09:56 -0700 From: Jim Schaad To: , 'Carsten Bormann' CC: 'Hannes Tschofenig' , 'core' , , References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <91797cd1747cf05db20d64662306e038@bbhmail.nl> In-Reply-To: <91797cd1747cf05db20d64662306e038@bbhmail.nl> Date: Wed, 20 Jun 2018 09:12:52 -0700 Message-ID: <001701d408b1$8cd2dd10$a6789730$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01D40876.E07564A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG/S+RHVkCkQxegzhC32weTrUzzBwIfwDTTAqVFXzMBqqx8WgLhhBh7AciFkcwCU/daGAI1GHuCAgGCadECFFGudgHA077GAxkWxyKjzjbOUA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 16:13:06 -0000 ------=_NextPart_000_0018_01D40876.E07564A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That sounds like a good plan forward. Are you also going to need an = early registration on the multipart-core draft as well? =20 Jim =20 =20 From: Peter van der Stok =20 Sent: Wednesday, June 20, 2018 3:07 AM To: Carsten Bormann Cc: Hannes Tschofenig ; core ; = ace@ietf.org; Jim Schaad ; rdd@cert.org Subject: Re: [core] [Ace] Early media-type registration for EST over = CoAP =20 HI Carsten, Jim Just to get this clear. We will update the the est-coaps draft by referring to = draft-fossati-core-multipart-ct-05 = for = the wanted early registration of the content formats specified in = est-coaps. Once done, we direct a request for early registration of the = content-format values to the ACE chairs. Although the corresponding media formats have not been allocated yet for = multipart-ct draft, the corresponding content-format numbers can be = allocated already. Is that the approved plan? Please confirm or specify the conditions on multipart-ct draft. Many thanks for your understanding, Peter Carsten Bormann schreef op 2018-06-19 14:22: On Jun 19, 2018, at 14:11, Carsten Bormann > wrote:=20 Since the registry that we are registering into does not fulfill the = preconditions of RFC 7120 Section 2 point (a), (Sorry, wasn't awake enough. If we go for the 256-9999 space, of course = it does. And we probably do.) So we'll have to follow the process according to Section 3 of RFC 7120. Starting with point (1) of Section 3.1: 1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and to which document they should be assigned. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0018_01D40876.E07564A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

That = sounds like a good plan forward.=C2=A0 Are you also going to need an = early registration on the multipart-core draft as well?

 

Jim

 

 

From: Peter = van der Stok <stokcons@bbhmail.nl>
Sent: Wednesday, = June 20, 2018 3:07 AM
To: Carsten Bormann = <cabo@tzi.org>
Cc: Hannes Tschofenig = <Hannes.Tschofenig@arm.com>; core <core@ietf.org>; = ace@ietf.org; Jim Schaad <ietf@augustcellars.com>; = rdd@cert.org
Subject: Re: [core] [Ace] Early media-type = registration for EST over CoAP

 

HI Carsten, = Jim

Just to get this clear.

We will update the the = est-coaps draft by referring to draft-fossati-core-multipart-ct-05 for the wanted early = registration of the content formats specified in est-coaps.
Once = done, we direct a request for early registration of the content-format = values to the ACE chairs.
Although the corresponding media formats = have not been allocated yet for multipart-ct draft, the corresponding = content-format numbers can be allocated already.

Is that the = approved plan?

Please confirm or specify the conditions on = multipart-ct draft.

Many thanks for your = understanding,

Peter

Carsten = Bormann schreef op 2018-06-19 14:22:

On Jun 19, 2018, at = 14:11, Carsten Bormann <cabo@tzi.org> wrote: =


Since the = registry that we are registering into does not fulfill the preconditions = of RFC 7120 Section 2 point (a),


(Sorry, wasn't awake enough.  If we go for the 256-9999 = space, of course it does.  And we probably do.)

So we'll = have to follow the process according to Section 3 of RFC = 7120.

Starting with point (1) of Section = 3.1:

   1.  The authors (editors) of the = document submit a request for = early
       allocation to the = Working Group chairs, specifying which = code
       points require early = allocation and to which document they = should
       be = assigned.

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

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

------=_NextPart_000_0018_01D40876.E07564A0-- From nobody Wed Jun 20 12:42:56 2018 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 06B4E130E0D; Wed, 20 Jun 2018 12:42:44 -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 4h5r5hTV5M9d; Wed, 20 Jun 2018 12:42:41 -0700 (PDT) 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 AE560130EE4; Wed, 20 Jun 2018 12:42:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 566DE20090; Wed, 20 Jun 2018 15:56:56 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 77CCB120B; Wed, 20 Jun 2018 15:39:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7593B1205; Wed, 20 Jun 2018 15:39:40 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: consultancy@vanderstok.org, "'Carsten Bormann'" , rdd@cert.org, "'Hannes Tschofenig'" , "'core'" , ace@ietf.org In-Reply-To: <001701d408b1$8cd2dd10$a6789730$@augustcellars.com> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <91797cd1747cf05db20d64662306e038@bbhmail.nl> <001701d408b1$8cd2dd10$a6789730$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 20 Jun 2018 19:42:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jim Schaad wrote: > That sounds like a good plan forward. Are you also going to need an e= arly > registration on the multipart-core draft as well? yes, it would be nice, ... we think that it's CORE's problem to adopt the draft and ask for that. The multipart response is only need for systems where the private key will = be generated on the EST server: and a number of implementers are keen *not* to do that, so the multipart is not urgent to as many people. > From: Peter van der Stok > Sent: Wednesday, June 20, 2018 3:07 AM > To: Carsten Bormann > Cc: Hannes Tschofenig ; core ; > ace@ietf.org; Jim Schaad ; rdd@cert.org > Subject: Re: [core] [Ace] Early media-type registration for EST over = CoAP > HI Carsten, Jim > Just to get this clear. > We will update the the est-coaps draft by referring to > draft-fossati-core-multipart-ct-05 for the wanted early registration = of the > content formats specified in est-coaps. > Once done, we direct a request for early registration of the content-= format > values to the ACE chairs. > Although the corresponding media formats have not been allocated yet = for > multipart-ct draft, the corresponding content-format numbers can be a= llocated > already. > Is that the approved plan? > Please confirm or specify the conditions on multipart-ct draft. > Many thanks for your understanding, > Peter > Carsten Bormann schreef op 2018-06-19 14:22: > On Jun 19, 2018, at 14:11, Carsten Bormann wrote: > Since the registry that we are registering into does not fulfill the > preconditions of RFC 7120 Section 2 point (a), > (Sorry, wasn't awake enough. If we go for the 256-9999 space, of cour= se > it does. And we probably do.) > So we'll have to follow the process according to Section 3 of RFC 712= 0. > Starting with point (1) of Section 3.1: > 1. The authors (editors) of the document submit a request for early > allocation to the Working Group chairs, specifying which code > points require early allocation and to which document they should > be assigned. > Gr=C3=BC=C3=9Fe, Carsten > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyqteYCLcPvd0N1lAQJDeQf/Wxplvtx7BCgcRrWgQ8Yhq9FdR1Uvqz2z aGuHbD+UnJZrUc2uyetnPiS91m9qS46gXSwRebnW/o1E4DuImSz9Yu/9iIgMI+Hz vyu5R91WeTA9THxS9EQSQA80waappdaSfxguZooGloY2f/RWK/OxFE7346txfrnT dRRu6L+byWKnetAHnoyLJviUH+htKaPgQ4Lw/Atfms5BPoJI3NnQkM8cUDlCQ1FX SYPaKdTfN3Lil2loqNPf2sjEahr/Yb75P3H0yIAvBl9iYJYe+dgeAMINEGlALruG 3PY2cYWWo+d/wrG1xfJMOtwUeh8kwWWeZgVgGYEscBqn+ol+TAJoug== =OoSh -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 20 23:15:17 2018 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 9F3E013102A; Wed, 20 Jun 2018 23:15:15 -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 Hh5e_62uBZU5; Wed, 20 Jun 2018 23:15:13 -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 8F3D9130EE8; Wed, 20 Jun 2018 23:15:13 -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 w5L6EsZw027079; Thu, 21 Jun 2018 08:14:54 +0200 (CEST) Received: from [192.168.217.102] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (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 41BBHy1TRfzDX9C; Thu, 21 Jun 2018 08:14:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <23428.1529523580@localhost> Date: Thu, 21 Jun 2018 08:14:53 +0200 Cc: Jim Schaad , rdd@cert.org, peter van der Stok , core , ace@ietf.org, Hannes Tschofenig X-Mao-Original-Outgoing-Id: 551254491.905203-3f43be2726a8c93fe69117e9d3863c85 Content-Transfer-Encoding: quoted-printable Message-Id: <48024F1A-13D4-4C45-A708-EA5495374225@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> <7198364E-F831-423F-8709-D96E152FD888@tzi.org> <91797cd1747cf05db20d64662306e038@bbhmail.nl> <001701d408b1$8cd2dd10$a6789730$@augustcellars.com> <23428.1529523580@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 06:15:16 -0000 Hi Michael, On Jun 20, 2018, at 21:39, Michael Richardson = wrote: >=20 > The multipart response is only need for systems where the private key = will be > generated on the EST server: and a number of implementers are keen = *not* to > do that, so the multipart is not urgent to as many people. That is good to know, so we (core) can wait for working-group adoption = (WGA call ends Monday) and go for early allocation then. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 21 05:57:13 2018 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 009911277CC; Thu, 21 Jun 2018 05:57:11 -0700 (PDT) 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.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152958583097.31598.7299105732024578392@ietfa.amsl.com> Date: Thu, 21 Jun 2018 05:57:10 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 12:57:11 -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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Sandeep S. Kumar Michael C. Richardson Martin Furuhed Shahid Raza Filename : draft-ietf-ace-coap-est-02.txt Pages : 39 Date : 2018-06-21 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows low-resource constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-02 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-02 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 Jun 21 08:11:41 2018 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 A9CF0130EC0 for ; Thu, 21 Jun 2018 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 MwOr1ACYNXCb for ; Thu, 21 Jun 2018 08:11:37 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0065.outbound.protection.outlook.com [104.47.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF0A1310BD for ; Thu, 21 Jun 2018 08:11:37 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=bSE24qi3DacF6+Hw887wPdJNHGas4yHqLjuYABzKqR4=; b=i+ZKWO8QEiFeEbnWaFIYNLu0TeNTKFeFPGOcPNpfKQBu9sqCiea1xP+f/4Ir7mwtRWTtvJzpZ1CXHb+yMU5NpROdA32xb4CFXLSfMgH+ak763W5Zuxdhegpciy0ot5r08DYboxgxioc/tt/307RroG6xM1ZQQwogXisqxGJLBtI= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1438.eurprd08.prod.outlook.com (10.167.210.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Thu, 21 Jun 2018 15:11:33 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 15:11:33 +0000 From: Hannes Tschofenig To: "ace@ietf.org" Thread-Topic: Standardizing Attestation Tokens Thread-Index: AdQJcgoqgXwfLEtqRz6hxwJZ4JJxBQ== Date: Thu, 21 Jun 2018 15:11:33 +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: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1438; 7:IPKu9KIVImZjDcrbl5T4QokQOe1Rtrm2i9BZAMZtVXAZgvLmhKRxpdtoiHzQtktHU4ALUHOaNnW8QDNbjOCr68ISF3IyxWB6YQIFGQtONkjL834zndWMPJyq5lsjkxKb7Kz51FSDwSQDWpq7dMcBQ65EtKDdEzLFsb42WjJQgfTPpGw1DAhJPfnUeOBnsyrpZ4cU/G9ut17YfZhGzgAksDMPt4CFyWWUf1QGdi747ZLu3pHlsKqxSoDUL44E4w9i x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2ab16f3b-0879-44ad-5410-08d5d789468b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1438; x-ms-traffictypediagnostic: VI1PR0801MB1438: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1438; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1438; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(39380400002)(346002)(39860400002)(40434004)(199004)(189003)(53754006)(7116003)(53936002)(2906002)(5660300001)(66066001)(3846002)(8676002)(5630700001)(3660700001)(81166006)(81156014)(6916009)(3280700002)(33656002)(6116002)(790700001)(1730700003)(25786009)(2501003)(6506007)(316002)(59450400001)(26005)(99286004)(5890100001)(7696005)(102836004)(2900100001)(476003)(186003)(5250100002)(86362001)(68736007)(486006)(97736004)(478600001)(14454004)(74316002)(72206003)(8936002)(106356001)(105586002)(7736002)(5640700003)(3480700004)(9686003)(55016002)(6306002)(6436002)(54896002)(966005)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1438; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CCa+z9ccoEzHuyZglB+LKJXIo7oN14CQKjGOEuz67+6J/BbeNvBwaE7TEPbe2YhERY1ACMTinkU0yLJg0isLnM/vHsIremNRyYMTqrLFd/I8XPaju0b+gksxQxbeKOUZyo8Yy84Pa6tHT/sF97PhHy4R84sPpTF0rHPO5O9KYQagRy7ccwOv2lfEjDcPm77tOhMBdu/LIRDDHc0h5dwIcSCSY/Jrfn8+JxweXX4wSQ2NO/Zj8gmdG2r9oYWeQmzkR4d5tWU6GgN/zv7OcLxny76ZcfQtrNMqDE7F+DamuTgSUN6MJh/uE34KZ6eM7Vf/vFCta0unucpFuxRrRaCijA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112C81D9FA2DA83D4797877FA760VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ab16f3b-0879-44ad-5410-08d5d789468b X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 15:11:33.5499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1438 Archived-At: Subject: [Ace] Standardizing Attestation Tokens X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 15:11:41 -0000 --_000_VI1PR0801MB2112C81D9FA2DA83D4797877FA760VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I would like to make you aware of work that will be discussed on attestatio= n on the EAT mailing list. Here is the link to the list: https://www.ietf.org/mailman/listinfo/eat Here is a document describing the idea: https://tools.ietf.org/html/draft-mandyam-eat-00 The work is relevant for IoT and non-IoT devices. Laurence and I are planning to organize a Bar BOF at the Montreal IETF meet= ing to entertain the idea. 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_VI1PR0801MB2112C81D9FA2DA83D4797877FA760VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I would like to make you aware of work that will be = discussed on attestation on the EAT mailing list. Here is the link to the l= ist:

https://www.ietf.org/mailman/listinfo/eat=

 

Here is a document describing the idea: <= /p>

https://tools.ietf.org/html/draft-mandyam-eat-00

 

The work is relevant for IoT and non-IoT devices.

 

Laurence and I are planning to organize a Bar BOF at= the Montreal IETF meeting to entertain the idea.

 

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_VI1PR0801MB2112C81D9FA2DA83D4797877FA760VI1PR0801MB2112_-- From nobody Thu Jun 21 08:15:27 2018 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 A9D95130EA4 for ; Thu, 21 Jun 2018 08:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, 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 fOu4C4vPvHdd for ; Thu, 21 Jun 2018 08:15:22 -0700 (PDT) Received: from mail-pl0-x241.google.com (mail-pl0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) (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 471A51292AD for ; Thu, 21 Jun 2018 08:15:22 -0700 (PDT) Received: by mail-pl0-x241.google.com with SMTP id o18-v6so1168220pll.12 for ; Thu, 21 Jun 2018 08:15:22 -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=EQi2QInT+ObkTAF11Fq3VKN6p+9uMwfov6UqQxvjTK4=; b=2OowmwkbQti4hRvd3CzX5KHvxJl26zfa1781HTDS8ip1OrG+rGaDitBMQUFYYQAOdY jVezThxSecPqZzYHzNfGPCfTxFLUI5xjuWVo6i3D8TKoafpCPQRh+f2NVzohQokbWDVd BOY9QdDRaGLv8IcdIQGCxa81J+lrTOXDRmdppFeFot9v7sdsfDdGgw4la4udJ3KnHNkr aLiOJyWdXAU/8qwbfRlzstnB1DrCrMif1FUCSqiE3YVujLKEuM86zP40Ats/kTRwwW5S SLq6jqUwoyT2ZvW2ivol2aWCHtmzM77SEDKD6bdd+c9rAriOe+v/rhOf4uf1QZeRVQhr nPfg== 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=EQi2QInT+ObkTAF11Fq3VKN6p+9uMwfov6UqQxvjTK4=; b=AXwm/8DREgfC2CC97v+ZtQABZRquSjbPRcensqlQjMfUZA4lhNcfE59jwXTfp+MeS2 l4kWDWcac7hLXM905mo94bhqmuwMgXqSxdGLo30h92Yhd217PXN+wYgzzG2q1nOYVmWe r6DSJI8+L03P/biofYw28mizy/vt9ho2pIL7YrSUdBdjtIUmUp9hOyy5p64jOQ8Ny49X 7jyLhQnRZx5epdx5gek07Cl1edqHmoGZdHE96FuPLLmE6gjpfbaJDq/MGDk/9TRrBJX/ 5sNmuVU4FMVT5uyV4WtDLvZx88gntiGuMlSDsbbbTId6CRWzOi/1A1886KTbuBd3lQTL Dvmg== X-Gm-Message-State: APt69E0LchhI5lk75zmXmYS59VOgRWAfqGDdiixf5qoi8z+pq4id+S37 7xq4id0ryL0TGzrCfRTgM5Ei7J5vmCqUjsI1CYcBMA== X-Google-Smtp-Source: ADUXVKJEVgYXHiGkd+4Bncdq69HPGy3N/ME3XLYe/dziTJQKQE5GyqkDZM3au/fnoF9fqVAV+73F4Zk1r+emJIZQ/x0= X-Received: by 2002:a17:902:b410:: with SMTP id x16-v6mr28685912plr.324.1529594121804; Thu, 21 Jun 2018 08:15:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:b28c:0:0:0:0 with HTTP; Thu, 21 Jun 2018 08:15:21 -0700 (PDT) In-Reply-To: <01c601d407f8$16621ec0$43265c40$@augustcellars.com> References: <01c601d407f8$16621ec0$43265c40$@augustcellars.com> From: Samuel Erdtman Date: Thu, 21 Jun 2018 17:15:21 +0200 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-oauth-authz@ietf.org, ace Content-Type: multipart/alternative; boundary="00000000000047ed70056f2862e0" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz -12 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 15:15:26 -0000 --00000000000047ed70056f2862e0 Content-Type: text/plain; charset="UTF-8" Thanks for reviewing, some answers inline On Tue, Jun 19, 2018 at 8:05 PM, Jim Schaad wrote: > Based on where I currently am, here is another review of the document. > > 1. In section 4 for Figure one: Is the term "RS Information" your term or > an OAuth term. When I see this I think of it as information for not about > the RS which I do not believe is the intent. > No, the intent is information about the RS for the client. It is described in "2. Terminology". Not sure if "client information" would be preferable. > > 2. In section 5.1 - I am unclear what the second paragraph is supposed to > be doing here. I think that you want state this different. Rather than > talking about the "desired resource" you may want to talk about the AS. > That would better match the title of the section. > The focus could maybe be different but the text is about how to find the AS but the method for that is quite RS focused. > > 3. In section 5.1 - There is a note in this section that does not seem to > be extremely useful. Where is this discussion go on? Is it still going > on? > I am not even sure if the statement about a common understanding of time is > correct? It seems that one can either add or not add the nonce as an RS > depending on if you think you understand a common time. > I have not heard anything on the time discussion for a while. > > 4. In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc. Given > the use of POP tokens, what is the reason for this draft and the text about > client credential types? (Put it this way. I did not need to implement > this for anything yet. Why is it here?) > Not sure what profile you have implemented. I-D.erdtman-ace-rpcc defines how the client can use Raw Public Key or Pre Shared Key with (D)TLS to authenticate it self to the AS. It is not a strange operation so you might have implemented it without thinking about it (Ludwig kind of did). I-D.erdtman-ace-rpcc is similar to draft-ietf-oauth-mtls that defines what was already done in the wild when it comes to x509 certificates and client authentication. Or you might have used default client credentials (client_id/username and client_secret/password). I think writing about client credentials is needed since the ACE use cases so far has been client centric, i.e. the client is often described to authenticate as it self to get a token and not as is common i OAuth the user is authenticated and authorizes the client to get a token. With that said the reference to I-D.erdtman-ace-rpcc should maybe be removed since interest in I-D.erdtman-ace-rpcc has been very limited. > > > > > Given 15 different introspection tokens, how do I decide which is the one > to > present to the AS - enumerate them? > > 'authorization code' vs 'decode code' grants > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --00000000000047ed70056f2862e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for reviewing, some answers inline

On Tue, Jun 19, 2018 at 8:05 P= M, Jim Schaad <ietf@augustcellars.com> wrote:
Based on where I currently am, = here is another review of the document.

1.=C2=A0 In section 4 for Figure one:=C2=A0 Is the term "RS Informatio= n" your term or
an OAuth term.=C2=A0 When I see this I think of it as information for not a= bout
the RS which I do not believe is the intent.

No, the intent is information about the RS for the client. It is desc= ribed in "2. Terminology".
Not sure if "client inf= ormation" would be preferable.
=C2=A0

2.=C2=A0 In section 5.1 - I am unclear what the second paragraph is suppose= d to
be doing here.=C2=A0 I think that you want state this different.=C2=A0 Rath= er than
talking about the "desired resource" you may want to talk about t= he AS.
That would better match the title of the section.

=
The focus could maybe be different but the text is about how to = find the AS but the method for that is quite RS focused.
=C2= =A0

3.=C2=A0 In section 5.1 - There is a note in this section that does not see= m to
be extremely useful.=C2=A0 Where is this discussion go on?=C2=A0 Is it stil= l going on?
I am not even sure if the statement about a common understanding of time is=
correct?=C2=A0 It seems that one can either add or not add the nonce as an = RS
depending on if you think you understand a common time.

I have not heard anything on the time discussion for a whi= le.
=C2=A0

4.=C2=A0 In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc.=C2= =A0 Given
the use of POP tokens, what is the reason for this draft and the text about=
client credential types?=C2=A0 (Put it this way.=C2=A0 I did not need to im= plement
this for anything yet.=C2=A0 Why is it here?)

Not sure what profile you have implemented.
I-D.erdtman-ac= e-rpcc defines how the client can use Raw Public Key or Pre Shared Key with= (D)TLS to authenticate it self to the AS. It is not a strange operation so= you might have implemented it without thinking about it (Ludwig kind of di= d). I-D.erdtman-ace-rpcc is similar to draft-ietf-oauth-mtls that defines w= hat was already done in the wild when it comes to x509 certificates and cli= ent authentication.
Or you might have used default client credent= ials (client_id/username and client_secret/password).

<= div>I think writing about client credentials is needed since the ACE use ca= ses so far has been client centric, i.e. the client is often described to a= uthenticate as it self to get a token and not as is common i OAuth the user= is authenticated and authorizes the client to get a token.
With = that said the reference to I-D.erdtman-ace-rpcc should maybe be removed sin= ce interest in I-D.erdtman-ace-rpcc has been very limited.
= =C2=A0




Given 15 different introspection tokens, how do I decide which is the one t= o
present to the AS - enumerate them?

'authorization code' vs 'decode code' grants


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

--00000000000047ed70056f2862e0-- From nobody Thu Jun 21 08:58:42 2018 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 2ECC3130ED8; Thu, 21 Jun 2018 08:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 vVFchqYyYBOP; Thu, 21 Jun 2018 08:58:37 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE7B12F1A5; Thu, 21 Jun 2018 08:58:36 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 21 Jun 2018 08:55:31 -0700 From: Jim Schaad To: 'Samuel Erdtman' CC: , 'ace' References: <01c601d407f8$16621ec0$43265c40$@augustcellars.com> In-Reply-To: Date: Thu, 21 Jun 2018 08:58:29 -0700 Message-ID: <010501d40978$b3e609f0$1bb21dd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01D4093E.07884360" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGLEpxdq+KzXOg+Dpd9ZesTRpusvAEa+pRKpPPtkEA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz -12 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 21 Jun 2018 15:58:41 -0000 ------=_NextPart_000_0106_01D4093E.07884360 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I sent this review early by accident (I thought I was sending a = different mail). =20 However a couple things below. =20 =20 From: Samuel Erdtman =20 Sent: Thursday, June 21, 2018 8:15 AM To: Jim Schaad Cc: draft-ietf-ace-oauth-authz@ietf.org; ace Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz -12 =20 Thanks for reviewing, some answers inline =20 On Tue, Jun 19, 2018 at 8:05 PM, Jim Schaad > wrote: Based on where I currently am, here is another review of the document. 1. In section 4 for Figure one: Is the term "RS Information" your term = or an OAuth term. When I see this I think of it as information for not = about the RS which I do not believe is the intent. =20 No, the intent is information about the RS for the client. It is = described in "2. Terminology". Not sure if "client information" would be preferable.=20 =20 [JLS] Yeah I agree that =E2=80=98client information=E2=80=99 is not = really any better. I wonder if =E2=80=98Access Information=E2=80=99 = might be a better term? =20 =20 2. In section 5.1 - I am unclear what the second paragraph is supposed = to be doing here. I think that you want state this different. Rather than talking about the "desired resource" you may want to talk about the AS. That would better match the title of the section. =20 The focus could maybe be different but the text is about how to find the = AS but the method for that is quite RS focused. =20 [JLS] This is not clear to me from what is stated. Does this mean that = there is going to be AS pointers that are contained on the RD entry for = the resource that one is interested in? If that is the case then a = pointer to where those fields are (going) to be defined would be useful. = I read this as searching the RD for an AS directly. =20 3. In section 5.1 - There is a note in this section that does not seem = to be extremely useful. Where is this discussion go on? Is it still going = on? I am not even sure if the statement about a common understanding of time = is correct? It seems that one can either add or not add the nonce as an RS depending on if you think you understand a common time. =20 I have not heard anything on the time discussion for a while. =20 4. In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc. = Given the use of POP tokens, what is the reason for this draft and the text = about client credential types? (Put it this way. I did not need to implement this for anything yet. Why is it here?) =20 Not sure what profile you have implemented. I-D.erdtman-ace-rpcc defines how the client can use Raw Public Key or = Pre Shared Key with (D)TLS to authenticate it self to the AS. It is not = a strange operation so you might have implemented it without thinking = about it (Ludwig kind of did). I-D.erdtman-ace-rpcc is similar to = draft-ietf-oauth-mtls that defines what was already done in the wild = when it comes to x509 certificates and client authentication. Or you might have used default client credentials (client_id/username = and client_secret/password). =20 I think writing about client credentials is needed since the ACE use = cases so far has been client centric, i.e. the client is often described = to authenticate as it self to get a token and not as is common i OAuth = the user is authenticated and authorizes the client to get a token. With that said the reference to I-D.erdtman-ace-rpcc should maybe be = removed since interest in I-D.erdtman-ace-rpcc has been very limited. =20 [JLS] I am implementing all of my credentials as being something that is = either a) cooked in to the device or b) as a COSE Key which is part of a = database which is read up by the program. As such I do not believe I am = using anything from this draft. Part of what I am trying to figure out = here is what the status of this document is and what dependencies the = Authz document has one it. Is it really informational? What does it do = for the Authz document to have it referenced? Should this document be = pushed up to a WG document because it is really needed? My = understanding from RFC6749 is that these are client credentials that are = being used in the HTTP authentication rather then the TLS client auth = layer below HTTP. On the other hand this is not completely clear. =20 [JLS] These are not finished questions =E2=80=93 not surprised you did = not respond. =20 Jim Given 15 different introspection tokens, how do I decide which is the = one to present to the AS - enumerate them? 'authorization code' vs 'decode code' grants _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_0106_01D4093E.07884360 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I sent = this review early by accident (I thought I was sending a different = mail).

 

However a couple things below.

 

 

From: = Samuel Erdtman <samuel@erdtman.se>
Sent: Thursday, June = 21, 2018 8:15 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-oauth-authz@ietf.org; ace = <ace@ietf.org>
Subject: Re: [Ace] Review of = draft-ietf-ace-oauth-authz -12

 

Thanks = for reviewing, some answers inline

 

On Tue, = Jun 19, 2018 at 8:05 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

Based on = where I currently am, here is another review of the = document.

1.  In section 4 for Figure one:  Is the term = "RS Information" your term or
an OAuth term.  When I = see this I think of it as information for not about
the RS which I do = not believe is the intent.

 

No, the intent is information about the RS for the = client. It is described in "2. = Terminology".

Not = sure if "client information" would be preferable. =

 

[JLS] Yeah I agree that =E2=80=98client = information=E2=80=99 is not really any better.=C2=A0 I wonder if = =E2=80=98Access Information=E2=80=99 might be a better = term?

 

 


2.  In section 5.1 - I am unclear what the = second paragraph is supposed to
be doing here.  I think that you = want state this different.  Rather than
talking about the = "desired resource" you may want to talk about the AS.
That = would better match the title of the = section.

 

The focus could maybe be different but the text is = about how to find the AS but the method for that is quite RS = focused.

 

[JLS] This is not clear to me from what is = stated.=C2=A0 Does this mean that there is going to be AS pointers that = are contained on the RD entry for the resource that one is interested = in?=C2=A0 If that is the case then a pointer to where those fields are = (going) to be defined would be useful.=C2=A0 I read this as searching = the RD for an AS directly.

 


3.  In section 5.1 - There is a note in this = section that does not seem to
be extremely useful.  Where is = this discussion go on?  Is it still going on?
I am not even sure = if the statement about a common understanding of time = is
correct?  It seems that one can either add or not add the = nonce as an RS
depending on if you think you understand a common = time.

 

I = have not heard anything on the time discussion for a = while.

 


4.  In section 5.3 - There is a reference to = I-D.erdtman-ace-rpcc.  Given
the use of POP tokens, what is the = reason for this draft and the text about
client credential = types?  (Put it this way.  I did not need to implement
this = for anything yet.  Why is it = here?)

 

Not sure what profile you have = implemented.

I-D.erdtman-ace-rpcc defines how the client can use = Raw Public Key or Pre Shared Key with (D)TLS to authenticate it self to = the AS. It is not a strange operation so you might have implemented it = without thinking about it (Ludwig kind of did). I-D.erdtman-ace-rpcc is = similar to draft-ietf-oauth-mtls that defines what was already done in = the wild when it comes to x509 certificates and client = authentication.

Or you = might have used default client credentials (client_id/username and = client_secret/password).

 

I = think writing about client credentials is needed since the ACE use cases = so far has been client centric, i.e. the client is often described to = authenticate as it self to get a token and not as is common i OAuth the = user is authenticated and authorizes the client to get a = token.

With that said the = reference to I-D.erdtman-ace-rpcc should maybe be removed since interest = in I-D.erdtman-ace-rpcc has been very limited.

 

[JLS] I am = implementing all of my credentials as being something that is either a) = cooked in to the device or b) as a COSE Key which is part of a database = which is read up by the program.=C2=A0 As such I do not believe I am = using anything from this draft.=C2=A0 Part of what I am trying to figure = out here is what the status of this document is and what dependencies = the Authz document has one it.=C2=A0 Is it really informational?=C2=A0 = What does it do for the Authz document to have it referenced?=C2=A0 = Should this document be pushed up to a WG document because it is really = needed?=C2=A0=C2=A0 My understanding from RFC6749 is that these are = client credentials that are being used in the HTTP authentication rather = then the TLS client auth layer below HTTP.=C2=A0=C2=A0 On the other hand = this is not completely clear.

 



[JLS] These are not finished questions = =E2=80=93 not surprised you did not respond.

 

Jim



Given = 15 different introspection tokens, how do I decide which is the one = to
present to the AS - enumerate them?

'authorization code' vs = 'decode code' = grants


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

 

------=_NextPart_000_0106_01D4093E.07884360-- From nobody Fri Jun 22 06:36:24 2018 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 34A75130E60 for ; Fri, 22 Jun 2018 06:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 LiElG29RJ2ME for ; Fri, 22 Jun 2018 06:36:19 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0057.outbound.protection.outlook.com [104.47.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4BC130E5E for ; Fri, 22 Jun 2018 06:36:18 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=FL+8nNlHj33y8nu6OmrO9XVNCXqpW9Eux8Z7yZtsK/s=; b=p0C2fr8x0TdfiLpTX45H+C8pg0TgUKbtZBJILHNXr8RwRQl948+nZvXolVCVgXc1jS0QxTs+1w/+tgU8/aR/ntOYi7Uqw9PkfdUW0jgKgeWqohFfGQH0Pu2QRi7h3BkPP4pKMnggqcb/WJXM8kH+Jyob85nuv0/E1ZegHNWZNqo= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1616.eurprd08.prod.outlook.com (10.167.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Fri, 22 Jun 2018 13:36:16 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.021; Fri, 22 Jun 2018 13:36:16 +0000 From: Hannes Tschofenig To: Roman Danyliw , "ace@ietf.org" Thread-Topic: "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdQJ/3hMPxiML8tzRZiI8rJseWPrOA== Date: Fri, 22 Jun 2018 13:36:16 +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.115.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1616; 7:2YROXirYX0spCieX/7yLK/sLCRoeM0OPaj9E0s5dCkHRehWW00+VwMzmhYHzBcpmmEEq7PF0J9B3tbuRQBD1db2hcy6wbpGncoiItfTBQUf0Q7C89ub7XUdm+Z0ke33hV7I7Jh56/4zvNJ6sOzxnhKV0Qch52/s1StaggTPfMujVHiFiV43k8qiM2gEGobjJQD7sgkxD08XVU5t33euQ/AHT5KwhdNqYXq1AP7/YtanabWgw/so5IBXnxvr9CViE x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 72181504-b601-4043-e8ef-08d5d845213c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1616; x-ms-traffictypediagnostic: VI1PR0801MB1616: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1616; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1616; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(39380400002)(396003)(346002)(40434004)(189003)(199004)(5660300001)(59450400001)(68736007)(86362001)(14454004)(2900100001)(102836004)(186003)(316002)(106356001)(105586002)(476003)(74316002)(6436002)(26005)(478600001)(72206003)(6506007)(7696005)(2906002)(99286004)(25786009)(305945005)(110136005)(3846002)(8936002)(3280700002)(9686003)(486006)(5890100001)(55016002)(5250100002)(6116002)(2501003)(66066001)(8676002)(53936002)(3660700001)(97736004)(7736002)(33656002)(81166006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1616; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 41LFObq5dBk+YJ9sEn6Xfi4Edg80q7LVEsUsLU9AbA+lxuJt8/5ZR9qx5QXOe4S3Pa8pFSnPtGXDv51HwLnfbOyHFZ2P0G7/Wyz/swgLZWqODO5YUmrwkrQ9W2HgPb+wRW6oIHBbSY2AwhRSBJ3NVXYwDaggOUfH+bt45yU2rEqoWA7v76IGCzdIo7IjguHt6fjvFBq9+0iWRnMASRi4PxTwjMDM3vrsBYvbqchFsMyC4lgzOpm+cGTscz9PHBhL8QMaogxMmvZG5sXZp40W4LCaNibplhxDPX+bB7Fa2Jd7kZrAqNQopajkn97uq6UquQaOkI71G/tLuaIVJ3UwSQ== 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: 72181504-b601-4043-e8ef-08d5d845213c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 13:36:16.4005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1616 Archived-At: Subject: [Ace] "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 13:36:22 -0000 Hi Roman, this is also a good question: > (3) (Editorial) Page 4, Section 3.0, I read to the end of this section by= which point there has been discussion of "sub" or "iss". I was left wonde= ring about how to interpret the case where both are present and none are. Here is the text from the draft: " The presenter can be identified in one of several ways by the CWT depending upon the application requirements. If the CWT contains a "sub" (subject) claim [CWT], the presenter is normally the subject identified by the CWT. (In some applications, the subject identifier will be relative to the issuer identified by the "iss" (issuer) claim [CWT].) If the CWT contains no "sub" claim, the presenter is normally the issuer identified by the CWT using the "iss" claim. The case in which the presenter is the subject of the CWT is analogous to Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one of the "sub" and "iss" claims is typically present in the CWT and some use cases may require that both be present. " The CWT PoP document does not define the subject or issuer claims. The document also not mandate a specific set of claims to be included in a = CWT since this is application profile specific. Hence, I am wondering whether we could shorten the paragraph above, which i= s actually a bit confusing. " This specification adds a new claim to offer the proof-of-possession functi= onality. There are various claims already defined and the IANA claims registry [REF]= contains the most up-to-date list of standardized claims. Application using the CWT functiona= lity define what claims have to be used. The presenter can, if necessary, be identified in one of several ways by = the CWT depending upon the application requirements. If the CWT contains a "sub" (subject) claim [CWT], the presenter is the subject identified by the CWT. In some cases, there CWT may not include a "sub" claim, which allows the presenter to remain anonymous. " 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. From nobody Fri Jun 22 06:36:30 2018 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 F34D9130E5E for ; Fri, 22 Jun 2018 06:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 FnmPS1mn6r8I for ; Fri, 22 Jun 2018 06:36:18 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0057.outbound.protection.outlook.com [104.47.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479C3130E58 for ; Fri, 22 Jun 2018 06:36:18 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=rv7yHmKUoMmrM7n6dQTjfq5qwPdb6XVgjEUQ6ZKihQY=; b=iLd1pPg7yglybDmPLY+/w5luKz4o0/CFKgxoNExumg9oI4JlChiK53FS6lUvs+G9xjWV5R31lgbVR6FmHWSUAmMmed6/l92rVGnOeVRFtyhsoOwaEBoSt9Z7UcV8dJLaX7qj6gqm2vDCdTiBg0kb7Sz3KcaAdW/NXzgvL+pPxRs= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1616.eurprd08.prod.outlook.com (10.167.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Fri, 22 Jun 2018 13:36:15 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.021; Fri, 22 Jun 2018 13:36:15 +0000 From: Hannes Tschofenig To: Roman Danyliw , "ace@ietf.org" Thread-Topic: Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdQJ+lWc2W0LPLoES1iMKd72DvNSVQ== Date: Fri, 22 Jun 2018 13:36:15 +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.115.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1616; 7:PYao8wgqtTm75+AZJHUT/XaaeH2q/SsjZrDw/rBuDiJNpZK2WQRYoENcBpC0mM6pZ1HQsING6ekQUC3+nHxkxGMRzfN/pzm2sWZFog7INSnKe0lyMPoq/pb3sPGRoR0FEs9siy0GtT1bY4vdmvjNwoLLa/royfO+G+dIYc2DfFAZ1+hVBlRMcUoZm8JhLTxN1GGIt9LCL/KhCMyQBNY58rsMko5X9h22LDbKQW6mkN0SLCpWg9EkCdcTeuCsYbng x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 25760215-b483-4486-6b88-08d5d84520b9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1616; x-ms-traffictypediagnostic: VI1PR0801MB1616: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1616; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1616; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(39380400002)(396003)(346002)(40434004)(189003)(199004)(5660300001)(59450400001)(68736007)(86362001)(14454004)(2900100001)(102836004)(186003)(316002)(106356001)(105586002)(476003)(74316002)(6436002)(26005)(478600001)(72206003)(6506007)(7696005)(2906002)(99286004)(25786009)(305945005)(110136005)(3846002)(8936002)(3280700002)(9686003)(486006)(5890100001)(55016002)(5250100002)(6116002)(2501003)(66066001)(8676002)(53936002)(3660700001)(97736004)(7736002)(33656002)(81166006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1616; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: B9xstJpMFJt6wDS+FbEPBN5YkxPtGY938aw5A3+Rb8u5kXZNKGPoE6vlsASmkOMIyqSEf/rjGedQv/5dOQ/cWHLJdytzGVwWqFX7GFBBd1hbJeAQv0RuJLAXAAR8AkU2gc2Ks2IB910GKVSjrFcViwWSEMJnLfBD46oNyCdfKO+Pm7cQ4ravM6BT3U7ZfPhRkoyION7i1VkHX9hXj82HCwiUdcYmY75xeVf/O6G2z4XPFaLvv+w1sDDL0+0HffoexztGKtv1To/7NndyI0VVnFIyZFkqXg5BiHcx3T0GU2gbR2MexBSLGdrmFvHOeUBUx+rlD+BujS0hMwfnYpjeeg== 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: 25760215-b483-4486-6b88-08d5d84520b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 13:36:15.4777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1616 Archived-At: Subject: [Ace] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 13:36:22 -0000 Hi Roman, Thanks for your review. As I was re-reading the reviews I spotted this comment: > (14) (Editorial) Page 8, Section 4, Per "Replay can also be avoided if = a sub-key is derived from a shared secret that is specific to the instance = of the PoP demonstration." PoP is spelled out everywhere else in this draf= t but here. Yes, the acronym is defined, but for readability, I recommend = against it using it and consistently spelling it out here too. I believe the current text is a bit confusing. Here is what it says: Proof of possession via encrypted symmetric secrets is subject to replay at= tacks. This attack can, for example, be avoided when a signed nonce or challenge i= s used since the recipient can use a distinct nonce or challenge for each interact= ion. Replay can also be avoided if a sub-key is derived from a shared secret that is specific to the instance of the proof-of-possession demonstration. This somehow gives the impression that replay attacks are only a concern fo= r symmetric key techniques. Of course, this is not true. Furthermore, the text gives the impression tha= t this attack is actually something that can be covered within the CWT-PoP token spec itself. This is= also not the case. For this reason I am suggesting to change the paragraph to: " CBOR Web Tokens with proof-of-possession keys are used in context of an arc= hitecture, such as ACE-OAuth [REF], where protocols are used by a presenter to request= these tokens and to subsequently use them with recipients. To avoid replay attacks when the = proof-of-possession tokens are sent to presenters a security protocol, which uses nonces or timestamps= , has to be utilized. Note that a discussion of the architecture or specific protocols CWT proof-= of-possession tokens are used with are outside the scope of this specification. " 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. From nobody Fri Jun 22 06:36:38 2018 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 35255130E58; Fri, 22 Jun 2018 06:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 dv8Pz7sR_PQM; Fri, 22 Jun 2018 06:36:21 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0057.outbound.protection.outlook.com [104.47.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6DB130E5F; Fri, 22 Jun 2018 06:36:19 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=5yc7S95bgUcu3POmbdsd/SpyM/M/2dxQ3/ahOkw1/dU=; b=kSyU+hjMx3+HQkash1N6GdlMbcMNUcvGo9lQ7c8MQXHCa5CE/GhdWdX/vxjfEnrD8XJpZA6VTPn3JHWPb8gUbNutYCuY7KHZCleG6aLmSGpsROCb5EqK4D52hAWGOOzQb22o3lBMAv/QdRSxWyq+/e6Hdo0AERMm+PeyBXHp64I= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1616.eurprd08.prod.outlook.com (10.167.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Fri, 22 Jun 2018 13:36:17 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.021; Fri, 22 Jun 2018 13:36:17 +0000 From: Hannes Tschofenig To: Jim Schaad , 'Mike Jones' , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" CC: "ace@ietf.org" Thread-Topic: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdQKFSUx11D9ChnERGKUCytum2t16A== Date: Fri, 22 Jun 2018 13:36:16 +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.115.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1616; 7:BHHQqOuSSYYaSGzsqGKqtUBNhZ8pJ40Id75rTfa43J6Hdg/kLamiTnDJvKWhk3u7xrvMTXkMo1q6fR8C7WD3y92IRKnoj73sGHi99NKzJwH4uBdh0+bhNf+ZZ/d+Zm7J6jRslMgseeistENO6SpHYtEayAwBCUIvsiVLU7VCyxHVs107NqUpmpK8Zv/Xa3aPLIVTC2VRqm2X8TbYd9bJAZw1xv4FpOYJiVoD3l9r1Oven3P+zseevroaD2OQgUfE x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d4e97ebd-ce90-4dca-476a-08d5d8452192 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1616; x-ms-traffictypediagnostic: VI1PR0801MB1616: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1616; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1616; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(39380400002)(396003)(346002)(40434004)(189003)(199004)(5660300001)(59450400001)(68736007)(86362001)(14454004)(2900100001)(102836004)(186003)(316002)(106356001)(105586002)(476003)(74316002)(6436002)(26005)(478600001)(72206003)(6506007)(7696005)(2906002)(561944003)(99286004)(25786009)(305945005)(110136005)(3846002)(4326008)(8936002)(3280700002)(1511001)(9686003)(486006)(5890100001)(55016002)(5250100002)(6116002)(8666007)(2501003)(66066001)(8676002)(53936002)(3660700001)(97736004)(7736002)(33656002)(81166006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1616; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qVjtSNA7cLzB/EK1I3dUjQtj5AJN4J4BD0t8j7EWUdiAuD6hNk61iUCWsTurbfDJdVHfs1tfDCwQ0RRuMGviFTAIixV6TlgwW42saXMqifY7eaGVBRXmw73qXzR01nqlA57sbzXzQPjXISzKWTvtf18RABWu2PqnR8BHjAUDdlmLNAth+fpKYerX/6SUDZdcpcSkSbmMyjx62yH/lNF6J6kBo4QLW7wiQeysEzPVD7mzo74QDoK2t5cIQXOZM+dKescgbTeyfrsTwr8yXpnrO2LrBDgOHUUIu6CjZL4rGE3jPxWErOjUa86ZeHlFJU80QdRFjMnVTXArdejHyT29cw== 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: d4e97ebd-ce90-4dca-476a-08d5d8452192 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 13:36:16.9680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1616 Archived-At: Subject: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 13:36:23 -0000 Hi Jim, I would like to comment on this issue. ----- > > 14. I have real problems w/ the use of a KID for POP identification. = It may > identify the wrong key or, if used for granting access, may have problems w/ > identity collisions. These need to be spelt out someplace to help people > tracking down questions of why can't I verify w/ this CWT, I know it's right. > > The Key ID is a hint to help identify which PoP key to use. Yes, if a Ke= y ID is > sent that doesn't correspond to the right PoP key, failures may occur. I view > that as usage bug - not a protocol problem. If keys aren't consistently known > and identified by both parties, there are lots of things that can go wrong, and > this is only one such instance. That said, I can try to say something about the > need for keys to be consistently and known by both parties, if you think that > would help. > My problem is that if there are two different people with the same Key ID= , either intentionally or unintentionally, then using the key ID to identify the key may allow the other person to masquerade as the first person. I am unworried about the instance of a failure to get a key based on a key id. That is not the problem you are proposing to address. ----- I think we should document this issue. Here is some text proposal that coul= d go into a separate operational consideration section (or into the security considerat= ion section instead). " - Operational Considerations The use of CWTs with proof-of-possession keys requires additional informati= on to be shared between the involved parties in order to ensure correct processing. The rec= ipient needs to be able to use credentials to verify the authenticity, integrity and potential= ly the confidentiality of the CWT and its content. This requires the recipient to know information ab= out the issuer. Like-wise there needs to be an upfront agreement between the issuer and the= recipient about the claims that need to be present and what degree of trust can be put into= those. When an issuer creates a CWT containing a key id claim, it needs to make su= re that it does not issue another CWT containing the same key id with a different content, or f= or a different subject, within the lifetime of the CWTs, unless intentionally desired. Failure to d= o so may allow one party to impersonate another party with the potential to gain additional privileg= es. " 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. From nobody Fri Jun 22 07:58:51 2018 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 6B32F130E8E; Fri, 22 Jun 2018 07:58:49 -0700 (PDT) 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 nDQ-SDfylyo6; Fri, 22 Jun 2018 07:58:47 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39791130E8B; Fri, 22 Jun 2018 07:58:47 -0700 (PDT) Received: from Jude (104.129.192.86) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 22 Jun 2018 07:55:42 -0700 From: Jim Schaad To: 'Hannes Tschofenig' , 'Mike Jones' , CC: References: In-Reply-To: Date: Fri, 22 Jun 2018 07:58:38 -0700 Message-ID: <01c501d40a39$82742390$875c6ab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oaNHTzaQ Content-Language: en-us X-Originating-IP: [104.129.192.86] Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 14:58:50 -0000 That language works if you assume that there is only one CWT that an RS will look to. If there are multiple CWTs then one needs coordination language between them. > -----Original Message----- > From: Hannes Tschofenig > Sent: Friday, June 22, 2018 6:36 AM > To: Jim Schaad ; 'Mike Jones' > ; draft-ietf-ace-cwt-proof-of- > possession@ietf.org > Cc: ace@ietf.org > Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > Hi Jim, > > I would like to comment on this issue. > > ----- > > > 14. I have real problems w/ the use of a KID for POP > > > identification. It > may > > identify the wrong key or, if used for granting access, may have > > problems > w/ > > identity collisions. These need to be spelt out someplace to help > > people tracking down questions of why can't I verify w/ this CWT, I > > know it's > right. > > > > The Key ID is a hint to help identify which PoP key to use. Yes, if a > > Key > ID is > > sent that doesn't correspond to the right PoP key, failures may occur. > > I > view > > that as usage bug - not a protocol problem. If keys aren't > > consistently > known > > and identified by both parties, there are lots of things that can go > wrong, and > > this is only one such instance. That said, I can try to say something > about the > > need for keys to be consistently and known by both parties, if you > > think > that > > would help. > > > My problem is that if there are two different people with the same Key > > ID, > either intentionally or unintentionally, then using the key ID to identify the > key may allow the other person to masquerade as the first person. I am > unworried about the instance of a failure to get a key based on a key id. > That is not the problem you are proposing to address. > > ----- > > I think we should document this issue. Here is some text proposal that could > go into a separate operational consideration section (or into the security > consideration section instead). > > " > - Operational Considerations > > The use of CWTs with proof-of-possession keys requires additional > information to be shared between the involved parties in order to ensure > correct processing. The recipient needs to be able to use credentials to verify > the authenticity, integrity and potentially the confidentiality of the CWT and > its content. This requires the recipient to know information about the issuer. > Like-wise there needs to be an upfront agreement between the issuer and > the recipient about the claims that need to be present and what degree of > trust can be put into those. > > When an issuer creates a CWT containing a key id claim, it needs to make > sure that it does not issue another CWT containing the same key id with a > different content, or for a different subject, within the lifetime of the CWTs, > unless intentionally desired. Failure to do so may allow one party to > impersonate another party with the potential to gain additional privileges. > " > > > 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. From nobody Fri Jun 22 13:43:55 2018 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 E8040130EF4; Fri, 22 Jun 2018 13:43:52 -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 yewJGUVTFFxQ; Fri, 22 Jun 2018 13:43:51 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 11D8C130EFF; Fri, 22 Jun 2018 13:43:50 -0700 (PDT) X-AuditID: 12074425-793ff700000042ec-28-5b2d5f86ba0b 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 1C.78.17132.68F5D2B5; Fri, 22 Jun 2018 16:43:50 -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 w5MKhnbR003901; Fri, 22 Jun 2018 16:43:49 -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 w5MKhi6U008647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2018 16:43:47 -0400 Date: Fri, 22 Jun 2018 15:43:44 -0500 From: Benjamin Kaduk To: Hannes Tschofenig Cc: Jim Schaad , "'Mike Jones'" , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Message-ID: <20180622204344.GP64617@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+NgFmphleLIzCtJLcpLzFFi42IRYrdT0W2L1402WLeI3eL7tx5mi5//rjNb 3Jxxisli9fTvbBZ7p31icWD1WDNvDaPHxjnT2TyWLPnJ5NG64y97AEsUl01Kak5mWWqRvl0C V0bj6j/sBdv5Knp2PGBsYDzC3cXIySEhYCJx5tcfxi5GLg4hgcVMEpen/2aGcDYySmyaP4MN wrnKJPFyZQc7SAuLgKrEnmvTWEBsNgEViYbuy8wgtoiAocTe5kOsIA3MAl8YJT48OMAKkhAW CJN48mAt0A4ODl6gfdM/lICEhQQSJI5Mmw02k1dAUOLkzCdgM5kFtCRu/HvJBFLOLCAtsfwf B0iYUyBR4sG+L0wgtqiAssTevkPsExgFZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5xanJusXJ iXl5qUW6Fnq5mSV6qSmlmxjBge2iuoNxzl+vQ4wCHIxKPLwaX3WihVgTy4orcw8xSnIwKYny 3qwACvEl5adUZiQWZ8QXleakFh9ilOBgVhLhdXsKlONNSaysSi3Kh0lJc7AoifPmLGKMFhJI TyxJzU5NLUgtgsnKcHAoSfAaxulGCwkWpaanVqRl5pQgpJk4OEGG8wAN3xMLVMNbXJCYW5yZ DpE/xagoJc57ASQhAJLIKM2D6wUlHons/TWvGMWBXhHmbQZZwQNMWnDdr4AGMwENrm7WAhlc koiQkmpgnDVvreYrG9+sCzH/+l194i+fstGbvKXb0clus3ryrddl8wzWiezxOqirvUdDPuND x+t7cb8Cdb6x/ErdJO123+mDGPOf+PD8dvYJ5ge9fil2txyQjGwQ4fK+6f3jx9OSE+uv98d2 NfWmFx68/P+3K7Oh+V+2xgd3DlU+m+CZcjBY6/L9uMn/lFiKMxINtZiLihMB8Hps8hcDAAA= Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 20:43:53 -0000 On Fri, Jun 22, 2018 at 01:36:16PM +0000, Hannes Tschofenig wrote: > Hi Jim, > > > > My problem is that if there are two different people with the same Key ID, > either intentionally or unintentionally, then using the key ID to identify > the key may allow the other person to masquerade as the first person. I am > unworried about the instance of a failure to get a key based on a key id. > That is not the problem you are proposing to address. > > ----- > > I think we should document this issue. Here is some text proposal that could go into a > separate operational consideration section (or into the security consideration section instead). > > " > - Operational Considerations > > The use of CWTs with proof-of-possession keys requires additional information to be shared > between the involved parties in order to ensure correct processing. The recipient needs to be > able to use credentials to verify the authenticity, integrity and potentially the confidentiality of > the CWT and its content. This requires the recipient to know information about the issuer. > Like-wise there needs to be an upfront agreement between the issuer and the recipient about > the claims that need to be present and what degree of trust can be put into those. > > When an issuer creates a CWT containing a key id claim, it needs to make sure that it does not > issue another CWT containing the same key id with a different content, or for a different subject, > within the lifetime of the CWTs, unless intentionally desired. Failure to do so may allow one party > to impersonate another party with the potential to gain additional privileges. > " When would this be "intentionally desired"? It seems like there would be better ways to share authorization between parties than to issue such duplicate CWTs. -Ben From nobody Fri Jun 22 13:44:48 2018 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 8B866130EEB; Fri, 22 Jun 2018 13:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 qzdX6j0KiQel; Fri, 22 Jun 2018 13:44:42 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0122.outbound.protection.outlook.com [104.47.38.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9420E130EEE; Fri, 22 Jun 2018 13:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CYoRdxEUug6kDSZi+8m9vfiQqzUBHpELuD15PlCd4Nc=; b=okJeNQBvKzeGB0az52Mp1dhsX3/qdhU05qvhPoTSEg994BlctuXyaqw7Ckgk8i8VZfIjEF8N/bpd2aHmz2zXfbN+S5quqpk1qAwZYNG4dhkWcDPuBsVAiNmtfPl8PK+wNkxaedAQgA8vs5bEO5CDi3l7D+frz0yyjtiI1bjZZQg= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0346.namprd00.prod.outlook.com (52.132.148.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.931.0; Fri, 22 Jun 2018 20:44:21 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747%2]) with mapi id 15.20.0930.000; Fri, 22 Jun 2018 20:44:20 +0000 From: Mike Jones To: Jim Schaad , Hannes Tschofenig , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" CC: "ace@ietf.org" Thread-Topic: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdQKFSUx11D9ChnERGKUCytum2t16AAJFr0AAAwJBlA= Date: Fri, 22 Jun 2018 20:44:20 +0000 Message-ID: References: <01c501d40a39$82742390$875c6ab0$@augustcellars.com> In-Reply-To: <01c501d40a39$82742390$875c6ab0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [8.46.76.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0346; 7:I5SY6dGywTRAav0BamCn92CScrlDalHE7Bkw37KWNYW2sYs9TK66S4KH79SuuI2iNpO1EWc+HBX7Ag+c0tUONBZgMU0mKr8WXTwDzmT3YblE5mpl3ut6yemSbUUAMV4jPe2mp98ZTg9NAoQ450fIarPqICNn5/2S0KXcsvRZOY9OCw9NUWnZ1m6gVqV4Y19hWaLO+0Kon3wnRuAzuBqNuuMBeZb6w+QgWHFZO1FS3HqmN67YljKTQsIRUD3VlV2n x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 28818eeb-5aff-4798-4f66-08d5d880ee63 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:MW2PR00MB0346; x-ms-traffictypediagnostic: MW2PR00MB0346: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(89211679590171)(192374486261705)(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(93006095)(93001095)(3002001)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0346; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0346; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(376002)(366004)(39860400002)(396003)(13464003)(189003)(199004)(53936002)(81166006)(2501003)(6246003)(110136005)(81156014)(316002)(14454004)(66066001)(22452003)(10290500003)(8676002)(3660700001)(478600001)(305945005)(2900100001)(68736007)(8936002)(106356001)(6116002)(8990500004)(10090500001)(4326008)(25786009)(105586002)(33656002)(86362001)(74316002)(3846002)(5890100001)(5660300001)(7736002)(5250100002)(72206003)(6436002)(99286004)(53546011)(9686003)(476003)(6506007)(26005)(229853002)(6346003)(486006)(2906002)(76176011)(86612001)(446003)(55016002)(7696005)(102836004)(59450400001)(186003)(11346002)(3280700002)(561944003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0346; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: aw/svAAj/L9scOju49P+3xUAECBGwVqfU8YUNmmh1z0CiWFbf3SPozN+GiJYwNbItTsE1q9935Q1IDM4hXc+1G4u0AtdHwmdvfDkbY0QBcyd2Aqnd7vlpvT8BLxHXfwiuwxJpCITcn16Zq+3+OdZt4ZnekZNn7wUVSIB3sB9VXqs60ESiQN3eIDh+4jVLhvKrmGJKOGe7JEkh6dn+sjRzDq0qsRn1LmMDbEuj4iXQXOSM3fofS2ByjDS3u7ZxRKeUtkiMrlobDJWhN3SQ/++TCXjwkqvoQG4u3iVj34IetuBYlas3DC+qkbbagDL/iv8kDtptzG57rwdc/sA0r8m4A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28818eeb-5aff-4798-4f66-08d5d880ee63 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 20:44:20.7731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0346 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 20:44:46 -0000 I think you're looking for language something along these lines, right Jim? "Likewise, if PoP keys are used for multiple different kinds of CWTs in an = application and the PoP keys are identified by Key IDs, care must be taken = to keep the keys for the different kinds of CWTs segregated so that an atta= cker cannot cause the wrong PoP key to be used by using a valid Key ID for = the wrong kind of CWT." -- Mike -----Original Message----- From: Jim Schaad =20 Sent: Friday, June 22, 2018 7:59 AM To: Hannes Tschofenig ; Mike Jones ; draft-ietf-ace-cwt-proof-of-possession@ietf.org Cc: ace@ietf.org Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-poss= ession-02 That language works if you assume that there is only one CWT that an RS wil= l look to. If there are multiple CWTs then one needs coordination language= between them. > -----Original Message----- > From: Hannes Tschofenig > Sent: Friday, June 22, 2018 6:36 AM > To: Jim Schaad ; 'Mike Jones' > ; draft-ietf-ace-cwt-proof-of-=20 > possession@ietf.org > Cc: ace@ietf.org > Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 >=20 > Hi Jim, >=20 > I would like to comment on this issue. >=20 > ----- > > > 14. I have real problems w/ the use of a KID for POP=20 > > > identification. It > may > > identify the wrong key or, if used for granting access, may have=20 > > problems > w/ > > identity collisions. These need to be spelt out someplace to help=20 > > people tracking down questions of why can't I verify w/ this CWT, I=20 > > know it's > right. > > > > The Key ID is a hint to help identify which PoP key to use. Yes, if=20 > > a Key > ID is > > sent that doesn't correspond to the right PoP key, failures may occur. > > I > view > > that as usage bug - not a protocol problem. If keys aren't=20 > > consistently > known > > and identified by both parties, there are lots of things that can go > wrong, and > > this is only one such instance. That said, I can try to say=20 > > something > about the > > need for keys to be consistently and known by both parties, if you=20 > > think > that > > would help. >=20 > > My problem is that if there are two different people with the same=20 > > Key ID, > either intentionally or unintentionally, then using the key ID to=20 > identify the > key may allow the other person to masquerade as the first person. I=20 > am unworried about the instance of a failure to get a key based on a key = id. > That is not the problem you are proposing to address. >=20 > ----- >=20 > I think we should document this issue. Here is some text proposal that could > go into a separate operational consideration section (or into the=20 > security consideration section instead). >=20 > " > - Operational Considerations >=20 > The use of CWTs with proof-of-possession keys requires additional=20 > information to be shared between the involved parties in order to=20 > ensure correct processing. The recipient needs to be able to use=20 > credentials to verify > the authenticity, integrity and potentially the confidentiality of the=20 > CWT and > its content. This requires the recipient to know information about the issuer. > Like-wise there needs to be an upfront agreement between the issuer=20 > and the recipient about the claims that need to be present and what=20 > degree of trust can be put into those. >=20 > When an issuer creates a CWT containing a key id claim, it needs to=20 > make sure that it does not issue another CWT containing the same key=20 > id with a different content, or for a different subject, within the=20 > lifetime of the CWTs, > unless intentionally desired. Failure to do so may allow one party to=20 > impersonate another party with the potential to gain additional privileges. > " >=20 >=20 > Ciao > Hannes >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are=20 > confidential and may also be privileged. If you are not the intended recipient, > please notify the sender immediately and do not disclose the contents=20 > to any > other person, use it for any purpose, or store or copy the information=20 > in any > medium. Thank you. From nobody Fri Jun 22 13:48:43 2018 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 A1182130EEB; Fri, 22 Jun 2018 13:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 y9a-hIUicFCT; Fri, 22 Jun 2018 13:48:39 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::71a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6FC130DF5; Fri, 22 Jun 2018 13:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JmWAXjJKWdQEWY7mNT8ZE1KJO6sOPSTq52Qpv3VIyzY=; b=OB6frzsTQ07apau1zhyui3hqlc2rOFGowVHRnZhi6AZJieudeYUKW2qrw4C/oQ/E5Po99nCpCAzCGPWQS1OUZF+j9veZVvE+lB34gDDH9hEBm7OGeR01Hzhq0oMToFXN8VY+HFJMXUsr0dvApGFohUtpYahReLQtV7+Y+7Ejbmw= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0315.namprd00.prod.outlook.com (52.132.148.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.931.0; Fri, 22 Jun 2018 20:48:35 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747%2]) with mapi id 15.20.0930.000; Fri, 22 Jun 2018 20:48:35 +0000 From: Mike Jones To: Benjamin Kaduk , Hannes Tschofenig CC: Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AQHUCmm+QBbDlvIEiEKYiqnkeWTVYaRsv4gg Date: Fri, 22 Jun 2018 20:48:35 +0000 Message-ID: References: <20180622204344.GP64617@kduck.kaduk.org> In-Reply-To: <20180622204344.GP64617@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [8.46.76.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0315; 7:5rAXeukcn/YsXq5HVvb6tJBwGbGJk43XKB7hDL0likJaO3CoBGXE343zQF70GSQRB9OxvG05vp1hvQP8RPLrZWzQBy8OltGUzGrDWxtLMxJ6rcA9ZNZOY+niWzh79rm/mrNE/1NIdTSNtiUNspqCbJF53RojbfxlwFzPK6J0DGdgh1Uos/UKrwn1w9hMkCGuTqRNlbIOIRwgbiTRf2Bw53LBtpqSABMSSQjECzx7XIwUGx1zf5xbX7w6cIoykeTj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bb31e0d3-3ede-4532-a11f-08d5d8818620 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:MW2PR00MB0315; x-ms-traffictypediagnostic: MW2PR00MB0315: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(89211679590171)(192374486261705)(223705240517415)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3002001)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0315; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0315; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39380400002)(376002)(39860400002)(396003)(13464003)(189003)(199004)(8990500004)(81156014)(106356001)(66066001)(9686003)(4326008)(6436002)(97736004)(186003)(68736007)(81166006)(2906002)(2171002)(3846002)(6116002)(76176011)(26005)(59450400001)(25786009)(102836004)(105586002)(53936002)(486006)(6246003)(316002)(478600001)(7736002)(3660700001)(7696005)(10290500003)(2900100001)(53546011)(3280700002)(305945005)(5660300001)(11346002)(561944003)(22452003)(5250100002)(10090500001)(72206003)(110136005)(33656002)(6506007)(86612001)(446003)(99286004)(8676002)(14454004)(55016002)(8936002)(229853002)(476003)(54906003)(74316002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0315; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Oo9rV9wLRgPjwVDw9ZLlVh1sDg8aK8HCHog0p23z+HPLU+eBhJkxmiC1sVVxzyArAK/w6gu1zxasvmgXJzFgevEgI6ch9nIrqrycav228vtwFGuhzdBMF7oM/Qk8Md5zdoeDJ1pkFggPyhRulUV3OO6TJm6betFJ5i2ul2mcalkaWLykOcNsd36pKqAtvn5AbXATTvnu41XvztwJHHkrzsV3Wmv5I3mnmDx6rWUx2GafoWIL6ZUTARfNJf/a8nQeUdCnltCkd85VBhxnYL6Ui+V9ZEmEWSsxe0nBjKrJCkGHCR5m9E5W7E3cR6OQAKbo7kZyddl6XIx3Og/6mvn3og== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: bb31e0d3-3ede-4532-a11f-08d5d8818620 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 20:48:35.3337 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0315 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 20:48:42 -0000 See my note just now proposing this text to Jim: "Likewise, if PoP keys are used for multiple different kinds of CWTs in an = application and the PoP keys are identified by Key IDs, care must be taken = to keep the keys for the different kinds of CWTs segregated so that an atta= cker cannot cause the wrong PoP key to be used by using a valid Key ID for = the wrong kind of CWT." As long as the PoP keys for different contexts are kept segregated, Key ID = collisions or reuse cause no problems. -- Mike -----Original Message----- From: Benjamin Kaduk =20 Sent: Friday, June 22, 2018 1:44 PM To: Hannes Tschofenig Cc: Jim Schaad ; Mike Jones ; draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-poss= ession-02 On Fri, Jun 22, 2018 at 01:36:16PM +0000, Hannes Tschofenig wrote: > Hi Jim, >=20 >=20 > > My problem is that if there are two different people with the same=20 > > Key ID, > either intentionally or unintentionally, then using the key ID to=20 > identify the key may allow the other person to masquerade as the first=20 > person. I am unworried about the instance of a failure to get a key base= d on a key id. > That is not the problem you are proposing to address. >=20 > ----- >=20 > I think we should document this issue. Here is some text proposal that=20 > could go into a separate operational consideration section (or into the s= ecurity consideration section instead). >=20 > " > - Operational Considerations >=20 > The use of CWTs with proof-of-possession keys requires additional=20 > information to be shared between the involved parties in order to=20 > ensure correct processing. The recipient needs to be able to use=20 > credentials to verify the authenticity, integrity and potentially the con= fidentiality of the CWT and its content. This requires the recipient to kno= w information about the issuer. > Like-wise there needs to be an upfront agreement between the issuer=20 > and the recipient about the claims that need to be present and what degre= e of trust can be put into those. >=20 > When an issuer creates a CWT containing a key id claim, it needs to=20 > make sure that it does not issue another CWT containing the same key=20 > id with a different content, or for a different subject, within the=20 > lifetime of the CWTs, unless intentionally desired. Failure to do so may = allow one party to impersonate another party with the potential to gain add= itional privileges. > " When would this be "intentionally desired"? It seems like there would be b= etter ways to share authorization between parties than to issue such duplic= ate CWTs. -Ben From nobody Fri Jun 22 13:59:38 2018 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 30E61130EF2 for ; Fri, 22 Jun 2018 13:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 O0Av7r7ONKAy for ; Fri, 22 Jun 2018 13:59:31 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710123.outbound.protection.outlook.com [40.107.71.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E216B130EEB for ; Fri, 22 Jun 2018 13:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s+NSnJKMdTUyNwoNe3uon6hH1dDemjKMRaNB5opDmvQ=; b=Lpj5kvrKwk2dQS+oqjdjl2grB/1sDtchmfIRD+RjMRtMwOHzF5YBqsY6ZdFeRzRwOsLJEN2Kkh6w/re0lTyPNixbYNLrxLF2/ZI7LMypUTdig4PXP+nV4Z43ws//k1CEOxFNLNEyyF6guZy6Z0pCw6verWXH5fGS4QmFeKXA31Q= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0346.namprd00.prod.outlook.com (52.132.148.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.931.0; Fri, 22 Jun 2018 20:59:29 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747%2]) with mapi id 15.20.0930.000; Fri, 22 Jun 2018 20:59:28 +0000 From: Mike Jones To: Hannes Tschofenig , Roman Danyliw , "ace@ietf.org" Thread-Topic: "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdQJ/3hMPxiML8tzRZiI8rJseWPrOAAbEEEg Date: Fri, 22 Jun 2018 20:59:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [8.46.76.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0346; 7:F2SAwxp9nuctbHcyws/HwSz2dEfRU2VQ+hxR69fdWyS47FcQ56az7noAqwxFk+ooT+OVBy2BrzqO6VlU4Ojru60tnRC9lz19eSC/+KCD2T6sUrh8uwF9FoUndoiwbmzXP4jTyCunhgSpNV+XFemb6QKpJ/Qi73/afkHcnxrdN7foLczmUkZ7pi+XkopFMOElu3dO3gqAaThbVtjuBosv6tXOzwYPJiX5Ydfzi1QOKPUNHTGwCj8DdNSralRTMxsM x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 941fc550-cff6-4436-7003-08d5d8830b81 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:MW2PR00MB0346; x-ms-traffictypediagnostic: MW2PR00MB0346: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0346; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0346; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(366004)(346002)(39380400002)(376002)(40434004)(13464003)(199004)(189003)(2906002)(486006)(26005)(229853002)(6346003)(76176011)(86612001)(99286004)(53546011)(6506007)(476003)(6306002)(9686003)(6436002)(97736004)(7696005)(446003)(55016002)(3280700002)(11346002)(102836004)(186003)(59450400001)(305945005)(478600001)(8936002)(68736007)(106356001)(2900100001)(53936002)(6246003)(110136005)(81156014)(316002)(2501003)(81166006)(8676002)(10290500003)(3660700001)(14454004)(22452003)(66066001)(86362001)(74316002)(3846002)(5250100002)(72206003)(5890100001)(5660300001)(7736002)(966005)(10090500001)(6116002)(8990500004)(105586002)(33656002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0346; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: F688knSPgvreOs9mF5h9FQvtyR43aFVTYA1uhE8KUFe2a2nKp9wjeYIGD5QMvLBUAedflDsP+UEQ9gsF8dDfgz3PaB9e/YFx6bPEpGvUtoRVqPCx53zEi78yr6HQnJ8rPx1MjWL9TDyWyb+sdl6DnoHJu5Xrhs+nctX/SkQ2NMVyIS8sJRJ+bEgNbb9cQW/2qEdIRbbCs9w0QAgeY67c2LSWUN+pffgguTJQcgF/uvpg5cebCR4AKSg3q8l2sQYNMewN1LVoOsHcEfiBD+moDPqAW0ekC71TGpdSX1239UDN8lNonWZBf3VMjEwS6i9uulip5QjAezWd1KiWMsxMrw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 941fc550-cff6-4436-7003-08d5d8830b81 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 20:59:28.5548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0346 Archived-At: Subject: Re: [Ace] "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 20:59:35 -0000 I'm working on simplifying this in a way similar to what Hannes proposed, a= nd in a way also previously promised to Jim (removing "normally", etc.), bu= t also in a way that makes it clear that the exactly claims to be used are = an application-specific choice. -- Mike -----Original Message----- From: Ace On Behalf Of Hannes Tschofenig Sent: Friday, June 22, 2018 6:36 AM To: Roman Danyliw ; ace@ietf.org Subject: [Ace] "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-= proof-of-possession-02 Hi Roman, this is also a good question: > (3) (Editorial) Page 4, Section 3.0, I read to the end of this section by= which point there has been discussion of "sub" or "iss". I was left wonde= ring about how to interpret the case where both are present and none are. Here is the text from the draft: " The presenter can be identified in one of several ways by the CWT depending upon the application requirements. If the CWT contains a "sub" (subject) claim [CWT], the presenter is normally the subject identified by the CWT. (In some applications, the subject identifier will be relative to the issuer identified by the "iss" (issuer) claim [CWT].) If the CWT contains no "sub" claim, the presenter is normally the issuer identified by the CWT using the "iss" claim. The case in which the presenter is the subject of the CWT is analogous to Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one of the "sub" and "iss" claims is typically present in the CWT and some use cases may require that both be present. " The CWT PoP document does not define the subject or issuer claims. The document also not mandate a specific set of claims to be included in a = CWT since this is application profile specific. Hence, I am wondering whether we could shorten the paragraph above, which i= s actually a bit confusing. " This specification adds a new claim to offer the proof-of-possession functi= onality. There are various claims already defined and the IANA claims registry [REF]= contains the most up-to-date list of standardized claims. Application usin= g the CWT functionality define what claims have to be used. The presenter can, if necessary, be identified in one of several ways by = the CWT depending upon the application requirements. If the CWT contains a "sub" (subject) claim [CWT], the presenter is the subject identified by the CWT. In some cases, there CWT may not include a "sub" claim, which allows the presenter to remain anonymous. " 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. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Fri Jun 22 14:06:38 2018 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 AE3BD130EF2 for ; Fri, 22 Jun 2018 14:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 mjokC5o8q39L for ; Fri, 22 Jun 2018 14:06:34 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE376130F20 for ; Fri, 22 Jun 2018 14:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mW5Hg52094kx/XB/sGsaOJg/PzCPnUzRC5addZ/NwYk=; b=XAbrFjs0vy/zpa5YXeuQql0EWzB1/+NBNQq9fGN0bA4cdpU4AGYbhXBmbOsEHohure4Xu+tvh6DDkb9Fr9RyuvyNYQcU2TideRzWrUBbjGLx6xKfmcyV+ftDntejunDLBPYaM3oTEFJDMY9rGiwhteik4kM4RjCq8DJ4MSkLrv0= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0443.namprd00.prod.outlook.com (52.132.149.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.935.0; Fri, 22 Jun 2018 21:06:30 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747%2]) with mapi id 15.20.0930.000; Fri, 22 Jun 2018 21:06:30 +0000 From: Mike Jones To: Hannes Tschofenig , Roman Danyliw , "ace@ietf.org" Thread-Topic: Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdQJ+lWc2W0LPLoES1iMKd72DvNSVQAcnizQ Date: Fri, 22 Jun 2018 21:06:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [8.46.76.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0443; 7:/zoTvdl8gr/fNhDwkIqkjRF1ExJMVz3gOsq3CCy+P3A8ETY9je2Dm1+IfouSGAzcW5PUY07fboD1C8xLus6Kx5tovJCLrXGkal4uHQgFD/zeW5tGqaCD/bBXyKa1opRXP3wt3WfIZxijsNwAfoCUxc1gGU6R5B0ycd/6XS/5WseoEOsDQ5G9H17fWWKY/K7TMhpewJ0LsrcsLC0nB//tfS3IFuu23cVPZRoi6V9I2irL1fuKDtXUszHzNaKcTXAB x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c17c8768-c107-4b92-fb79-08d5d88406a3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:MW2PR00MB0443; x-ms-traffictypediagnostic: MW2PR00MB0443: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(10201501046)(3231254)(2018427008)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0443; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0443; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(366004)(39860400002)(39380400002)(40434004)(189003)(199004)(13464003)(53936002)(26005)(66066001)(6306002)(6246003)(305945005)(33656002)(186003)(7736002)(110136005)(59450400001)(53546011)(6506007)(7696005)(316002)(76176011)(22452003)(25786009)(74316002)(8990500004)(102836004)(106356001)(10090500001)(105586002)(9686003)(486006)(3280700002)(81156014)(81166006)(966005)(8936002)(2906002)(14454004)(6116002)(3846002)(2900100001)(5250100002)(2501003)(5890100001)(8676002)(478600001)(99286004)(55016002)(10290500003)(86362001)(86612001)(97736004)(11346002)(72206003)(68736007)(5660300001)(476003)(3660700001)(229853002)(6436002)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0443; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: JYkQeWXS4F390becKjrCYwZEi5AQJO6252K7Jk3ZE5pBDcq0u3u/Dwm5O/MpLG6s+NGMTKO4T3Ndd64GNVkabUnCvcwQJsZodgdkJN49GkY+JOQGIDdLvBAEtuGV2RfNJpPT5OCML2/MqgNSp90INCt3lt1uhgFU2GKroTj/3+M6mHen05cocg0T78QlaJ1AO4WKxes5CYnJaZwDT7eQ0/6Ojv9a8Tv40PCSKK9KjQ/I3B4NmQz6VPoQu8rn+yyn54vEr4dhubLtskFvaaFj93peMEUKPoVITQ1+o4FI9pIRaypYjFqAep8QtX27L1APXkgoabP4RSScW0/aorpZL9R/QnNeiLnRGtjXTX8dyAg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c17c8768-c107-4b92-fb79-08d5d88406a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 21:06:30.1185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0443 Archived-At: Subject: Re: [Ace] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 22 Jun 2018 21:06:37 -0000 I agree with this proposed update and will apply it to the editor's draft. -----Original Message----- From: Ace On Behalf Of Hannes Tschofenig Sent: Friday, June 22, 2018 6:36 AM To: Roman Danyliw ; ace@ietf.org Subject: [Ace] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-= possession-02 Hi Roman, Thanks for your review. As I was re-reading the reviews I spotted this comment: > (14) (Editorial) Page 8, Section 4, Per "Replay can also be avoided if = a sub-key is derived from a shared secret that is specific to the instance = of the PoP demonstration." PoP is spelled out everywhere else in this draf= t but here. Yes, the acronym is defined, but for readability, I recommend = against it using it and consistently spelling it out here too. I believe the current text is a bit confusing. Here is what it says: Proof of possession via encrypted symmetric secrets is subject to replay at= tacks. This attack can, for example, be avoided when a signed nonce or challenge i= s used since the recipient can use a distinct nonce or challenge for each i= nteraction. Replay can also be avoided if a sub-key is derived from a shared secret tha= t is specific to the instance of the proof-of-possession demonstration. This somehow gives the impression that replay attacks are only a concern fo= r symmetric key techniques. Of course, this is not true. Furthermore, the text gives the impression tha= t this attack is actually something that can be covered within the CWT-PoP = token spec itself. This is also not the case. For this reason I am suggesting to change the paragraph to: " CBOR Web Tokens with proof-of-possession keys are used in context of an arc= hitecture, such as ACE-OAuth [REF], where protocols are used by a presenter= to request these tokens and to subsequently use them with recipients. To a= void replay attacks when the proof-of-possession tokens are sent to present= ers a security protocol, which uses nonces or timestamps, has to be utilize= d. Note that a discussion of the architecture or specific protocols CWT proof-= of-possession tokens are used with are outside the scope of this specificat= ion. " 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. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Sat Jun 23 09:03:56 2018 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 D1188130E8B; Sat, 23 Jun 2018 09:03:54 -0700 (PDT) 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 9N4n6NCyijKG; Sat, 23 Jun 2018 09:03:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68A9130E88; Sat, 23 Jun 2018 09:03:51 -0700 (PDT) Received: from Jude (151.127.12.101) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 23 Jun 2018 09:00:42 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'Hannes Tschofenig' CC: 'Mike Jones' , , References: <20180622204344.GP64617@kduck.kaduk.org> In-Reply-To: <20180622204344.GP64617@kduck.kaduk.org> Date: Sat, 23 Jun 2018 18:03:40 +0200 Message-ID: <023601d40b0b$c2df58f0$489e0ad0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQHH3wOzozq01UA= Content-Language: en-us X-Originating-IP: [151.127.12.101] Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 23 Jun 2018 16:03:55 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Friday, June 22, 2018 10:44 PM > To: Hannes Tschofenig > Cc: Jim Schaad ; 'Mike Jones' > ; draft-ietf-ace-cwt-proof-of- > possession@ietf.org; ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > On Fri, Jun 22, 2018 at 01:36:16PM +0000, Hannes Tschofenig wrote: > > Hi Jim, > > > > > > > My problem is that if there are two different people with the same > > > Key ID, > > either intentionally or unintentionally, then using the key ID to > > identify the key may allow the other person to masquerade as the first > > person. I am unworried about the instance of a failure to get a key based > on a key id. > > That is not the problem you are proposing to address. > > > > ----- > > > > I think we should document this issue. Here is some text proposal that > > could go into a separate operational consideration section (or into the > security consideration section instead). > > > > " > > - Operational Considerations > > > > The use of CWTs with proof-of-possession keys requires additional > > information to be shared between the involved parties in order to > > ensure correct processing. The recipient needs to be able to use > > credentials to verify the authenticity, integrity and potentially the > confidentiality of the CWT and its content. This requires the recipient to > know information about the issuer. > > Like-wise there needs to be an upfront agreement between the issuer > > and the recipient about the claims that need to be present and what > degree of trust can be put into those. > > > > When an issuer creates a CWT containing a key id claim, it needs to > > make sure that it does not issue another CWT containing the same key > > id with a different content, or for a different subject, within the > > lifetime of the CWTs, unless intentionally desired. Failure to do so may > allow one party to impersonate another party with the potential to gain > additional privileges. > > " > > When would this be "intentionally desired"? It seems like there would be > better ways to share authorization between parties than to issue such > duplicate CWTs. One case where this is desired is if you issue a second CWT with additional permissions for a client and you want to tie it to the same key. You could either duplicate the key or just reference it by ID. Jim > > -Ben From nobody Sat Jun 23 09:05:40 2018 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 0E3CE130E88; Sat, 23 Jun 2018 09:05:39 -0700 (PDT) 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 edkX_5cU6175; Sat, 23 Jun 2018 09:05:35 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8CD130E8B; Sat, 23 Jun 2018 09:05:35 -0700 (PDT) Received: from Jude (151.127.12.101) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 23 Jun 2018 09:02:28 -0700 From: Jim Schaad To: 'Mike Jones' , 'Hannes Tschofenig' , CC: References: <01c501d40a39$82742390$875c6ab0$@augustcellars.com> In-Reply-To: Date: Sat, 23 Jun 2018 18:05:27 +0200 Message-ID: <023701d40b0c$0244bf80$06ce3e80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQG8s+LeAddrJ3CjLFNrcA== Content-Language: en-us X-Originating-IP: [151.127.12.101] Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 23 Jun 2018 16:05:39 -0000 No not really, Hannes's language is much closer to what I am looking for. I don't care if they are different kinds of CWTs. I care about impersonation. > -----Original Message----- > From: Mike Jones > Sent: Friday, June 22, 2018 10:44 PM > To: Jim Schaad ; Hannes Tschofenig > ; draft-ietf-ace-cwt-proof-of- > possession@ietf.org > Cc: ace@ietf.org > Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > I think you're looking for language something along these lines, right Jim? > > "Likewise, if PoP keys are used for multiple different kinds of CWTs in an > application and the PoP keys are identified by Key IDs, care must be taken to > keep the keys for the different kinds of CWTs segregated so that an attacker > cannot cause the wrong PoP key to be used by using a valid Key ID for the > wrong kind of CWT." > > -- Mike > > -----Original Message----- > From: Jim Schaad > Sent: Friday, June 22, 2018 7:59 AM > To: Hannes Tschofenig ; Mike Jones > ; draft-ietf-ace-cwt-proof-of- > possession@ietf.org > Cc: ace@ietf.org > Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > That language works if you assume that there is only one CWT that an RS will > look to. If there are multiple CWTs then one needs coordination language > between them. > > > -----Original Message----- > > From: Hannes Tschofenig > > Sent: Friday, June 22, 2018 6:36 AM > > To: Jim Schaad ; 'Mike Jones' > > ; draft-ietf-ace-cwt-proof-of- > > possession@ietf.org > > Cc: ace@ietf.org > > Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Hi Jim, > > > > I would like to comment on this issue. > > > > ----- > > > > 14. I have real problems w/ the use of a KID for POP > > > > identification. It > > may > > > identify the wrong key or, if used for granting access, may have > > > problems > > w/ > > > identity collisions. These need to be spelt out someplace to help > > > people tracking down questions of why can't I verify w/ this CWT, I > > > know it's > > right. > > > > > > The Key ID is a hint to help identify which PoP key to use. Yes, if > > > a Key > > ID is > > > sent that doesn't correspond to the right PoP key, failures may occur. > > > I > > view > > > that as usage bug - not a protocol problem. If keys aren't > > > consistently > > known > > > and identified by both parties, there are lots of things that can go > > wrong, and > > > this is only one such instance. That said, I can try to say > > > something > > about the > > > need for keys to be consistently and known by both parties, if you > > > think > > that > > > would help. > > > > > My problem is that if there are two different people with the same > > > Key ID, > > either intentionally or unintentionally, then using the key ID to > > identify > the > > key may allow the other person to masquerade as the first person. I > > am unworried about the instance of a failure to get a key based on a key id. > > That is not the problem you are proposing to address. > > > > ----- > > > > I think we should document this issue. Here is some text proposal that > could > > go into a separate operational consideration section (or into the > > security consideration section instead). > > > > " > > - Operational Considerations > > > > The use of CWTs with proof-of-possession keys requires additional > > information to be shared between the involved parties in order to > > ensure correct processing. The recipient needs to be able to use > > credentials to > verify > > the authenticity, integrity and potentially the confidentiality of the > > CWT > and > > its content. This requires the recipient to know information about the > issuer. > > Like-wise there needs to be an upfront agreement between the issuer > > and the recipient about the claims that need to be present and what > > degree of trust can be put into those. > > > > When an issuer creates a CWT containing a key id claim, it needs to > > make sure that it does not issue another CWT containing the same key > > id with a different content, or for a different subject, within the > > lifetime of the > CWTs, > > unless intentionally desired. Failure to do so may allow one party to > > impersonate another party with the potential to gain additional > privileges. > > " > > > > > > 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. From nobody Sat Jun 23 09:06:52 2018 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 40BFA130E8B; Sat, 23 Jun 2018 09:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 VoCa6T6Dz5FW; Sat, 23 Jun 2018 09:06:49 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730113.outbound.protection.outlook.com [40.107.73.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11886130E88; Sat, 23 Jun 2018 09:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=18bAZZ2o8G+k4B4/GzcILCFPVyBTmHK+zMDGrJRY+GU=; b=j/1gm+JPzwBcV9OEcwi2AMtwrMv9+D5NSJazNjSBvuzYMVjWoJvBG3HTCkojQl2dGyliUs5+HSEW6NbEjlDylxBxQ/uHi9Qs0iv3kA9MsMBH0ZaYfgQ6bb1mXk135hP1VILQDx8KTBWK6Frs9xoTFT/mq5GTq0ZxO+RA5ntv0pI= Received: from SN6PR00MB0304.namprd00.prod.outlook.com (52.132.117.158) by SN6PR00MB0415.namprd00.prod.outlook.com (52.132.118.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.936.0; Sat, 23 Jun 2018 16:06:42 +0000 Received: from SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::cca8:e9e5:3691:f597]) by SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::cca8:e9e5:3691:f597%4]) with mapi id 15.20.0937.000; Sat, 23 Jun 2018 16:06:42 +0000 From: Mike Jones To: Jim Schaad , Hannes Tschofenig , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" CC: "ace@ietf.org" Thread-Topic: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdQKFSUx11D9ChnERGKUCytum2t16AAJFr0AAAwJBlAAKJb3gAAABUeA Date: Sat, 23 Jun 2018 16:06:42 +0000 Message-ID: References: <01c501d40a39$82742390$875c6ab0$@augustcellars.com> <023701d40b0c$0244bf80$06ce3e80$@augustcellars.com> In-Reply-To: <023701d40b0c$0244bf80$06ce3e80$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.16.94.99] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0415; 7:9MEjbO6zJk1Ol+cGYyFRCglyOOUZ16WiSOVoauklxPc/hP0rVtVwOdXLCYGfYNbDIIbZnAX391/fxn6doPFXNpFSiCkEeSZtfMJcIRhKK4Tf0YHIxCd+zXM6owNPd4EHmrFHZF85V1azBwA7vsViKt8oyYgPUznMKe+35u/vq2npGw+hI3Zaxd0wN4BdJauwbguD0+gdt/6ioefzBbxbPFAe+af4RqJFs1LrAI55IZQD/AZSGmbxB6wSJFUs012S x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 67c59c2b-8bb2-439f-5ca0-08d5d9234f74 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:SN6PR00MB0415; x-ms-traffictypediagnostic: SN6PR00MB0415: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(89211679590171)(192374486261705)(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231254)(2018427008)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0415; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0415; x-forefront-prvs: 07126E493C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(396003)(376002)(39380400002)(39860400002)(13464003)(199004)(189003)(554214002)(3846002)(86362001)(2900100001)(14454004)(86612001)(81156014)(81166006)(102836004)(8990500004)(8936002)(26005)(561944003)(6116002)(6346003)(7696005)(72206003)(76176011)(93886005)(4326008)(33656002)(10090500001)(6506007)(110136005)(66066001)(5660300001)(316002)(10290500003)(22452003)(25786009)(6246003)(478600001)(229853002)(99286004)(97736004)(11346002)(3280700002)(2906002)(53936002)(3660700001)(9686003)(446003)(486006)(106356001)(105586002)(476003)(2501003)(305945005)(186003)(5250100002)(53546011)(74316002)(8676002)(5890100001)(7736002)(6436002)(59450400001)(68736007)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0415; H:SN6PR00MB0304.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: uOgMAGRvzxLDSOfqIR0HAdorSGFRlyzfR089IPaqWwr2WyHAt/IVWrkeYPWrE0GzICY6cWBAnpasw5o0PnzlML0jNIJ/jxQLFlkZta6EKfhspx0QwJZpe7SXlrSv508ozHyrULroZUhijTfIKupJq3mqn6vgoh2Pi4bZxoFHPFyeFE9O2kXS9w5S//BnB6hBAKEbhPMwmCFxLLpCvvFd4hlA6hksg6vqvKLbqPJDOamvRG+N3DbzDxD7D8qzRqrIY30uJZd3OaD3Pxn9PHcPocBKFQCRJjYtWUZrZvakyyst+U/nueqW4QLxyisnzStf7NHAZPhIF59f6OYWIglxuupCS9P5rDgzAknpm2jQAAA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 67c59c2b-8bb2-439f-5ca0-08d5d9234f74 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2018 16:06:42.1220 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0415 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 23 Jun 2018 16:06:51 -0000 The sentence I sent was in addition to Hannes language to address the multi= ple CWT case discussed in the thread - not a replacement for it. -- Mike -----Original Message----- From: Jim Schaad =20 Sent: Saturday, June 23, 2018 9:05 AM To: Mike Jones ; Hannes Tschofenig ; draft-ietf-ace-cwt-proof-of-possession@ietf.org Cc: ace@ietf.org Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-poss= ession-02 No not really, Hannes's language is much closer to what I am looking for. = I don't care if they are different kinds of CWTs. I care about impersonati= on. > -----Original Message----- > From: Mike Jones > Sent: Friday, June 22, 2018 10:44 PM > To: Jim Schaad ; Hannes Tschofenig=20 > ; draft-ietf-ace-cwt-proof-of-=20 > possession@ietf.org > Cc: ace@ietf.org > Subject: RE: Key IDs ... RE: [Ace] WGLC on=20 > draft-ietf-ace-cwt-proof-of- > possession-02 >=20 > I think you're looking for language something along these lines, right Jim? >=20 > "Likewise, if PoP keys are used for multiple different kinds of CWTs=20 > in an application and the PoP keys are identified by Key IDs, care=20 > must be taken to > keep the keys for the different kinds of CWTs segregated so that an attacker > cannot cause the wrong PoP key to be used by using a valid Key ID for=20 > the wrong kind of CWT." >=20 > -- Mike >=20 > -----Original Message----- > From: Jim Schaad > Sent: Friday, June 22, 2018 7:59 AM > To: Hannes Tschofenig ; Mike Jones=20 > ; draft-ietf-ace-cwt-proof-of-=20 > possession@ietf.org > Cc: ace@ietf.org > Subject: RE: Key IDs ... RE: [Ace] WGLC on=20 > draft-ietf-ace-cwt-proof-of- > possession-02 >=20 > That language works if you assume that there is only one CWT that an=20 > RS will > look to. If there are multiple CWTs then one needs coordination=20 > language between them. >=20 > > -----Original Message----- > > From: Hannes Tschofenig > > Sent: Friday, June 22, 2018 6:36 AM > > To: Jim Schaad ; 'Mike Jones' > > ; draft-ietf-ace-cwt-proof-of-=20 > > possession@ietf.org > > Cc: ace@ietf.org > > Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Hi Jim, > > > > I would like to comment on this issue. > > > > ----- > > > > 14. I have real problems w/ the use of a KID for POP=20 > > > > identification. It > > may > > > identify the wrong key or, if used for granting access, may have=20 > > > problems > > w/ > > > identity collisions. These need to be spelt out someplace to help=20 > > > people tracking down questions of why can't I verify w/ this CWT,=20 > > > I know it's > > right. > > > > > > The Key ID is a hint to help identify which PoP key to use. Yes,=20 > > > if a Key > > ID is > > > sent that doesn't correspond to the right PoP key, failures may occur= . > > > I > > view > > > that as usage bug - not a protocol problem. If keys aren't=20 > > > consistently > > known > > > and identified by both parties, there are lots of things that can=20 > > > go > > wrong, and > > > this is only one such instance. That said, I can try to say=20 > > > something > > about the > > > need for keys to be consistently and known by both parties, if you=20 > > > think > > that > > > would help. > > > > > My problem is that if there are two different people with the same=20 > > > Key ID, > > either intentionally or unintentionally, then using the key ID to=20 > > identify > the > > key may allow the other person to masquerade as the first person. I=20 > > am unworried about the instance of a failure to get a key based on a=20 > > key id. > > That is not the problem you are proposing to address. > > > > ----- > > > > I think we should document this issue. Here is some text proposal=20 > > that > could > > go into a separate operational consideration section (or into the=20 > > security consideration section instead). > > > > " > > - Operational Considerations > > > > The use of CWTs with proof-of-possession keys requires additional=20 > > information to be shared between the involved parties in order to=20 > > ensure correct processing. The recipient needs to be able to use=20 > > credentials to > verify > > the authenticity, integrity and potentially the confidentiality of=20 > > the CWT > and > > its content. This requires the recipient to know information about=20 > > the > issuer. > > Like-wise there needs to be an upfront agreement between the issuer=20 > > and the recipient about the claims that need to be present and what=20 > > degree of trust can be put into those. > > > > When an issuer creates a CWT containing a key id claim, it needs to=20 > > make sure that it does not issue another CWT containing the same key=20 > > id with a different content, or for a different subject, within the=20 > > lifetime of the > CWTs, > > unless intentionally desired. Failure to do so may allow one party=20 > > to impersonate another party with the potential to gain additional > privileges. > > " > > > > > > Ciao > > Hannes > > > > IMPORTANT NOTICE: The contents of this email and any attachments are=20 > > confidential and may also be privileged. If you are not the intended > recipient, > > please notify the sender immediately and do not disclose the=20 > > contents to > any > > other person, use it for any purpose, or store or copy the=20 > > information in > any > > medium. Thank you. From nobody Sat Jun 23 13:23:37 2018 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 D3C62130ED7 for ; Sat, 23 Jun 2018 13:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, 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 PNU2-89yd0lX for ; Sat, 23 Jun 2018 13:23:31 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 238D9130ED4 for ; Sat, 23 Jun 2018 13:23:30 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id n2-v6so957776pgq.6 for ; Sat, 23 Jun 2018 13:23:30 -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=ZFXrx1mroYNZZ+Jm9SMnugMVl5KvJLjmSS+72vS34FY=; b=G5CgaolDViOCexXs1vHxneKAheQL7C/4YfasQfGMEumcD9YUE/AEJAnYJbUWJFbOB/ LSVWfAjrZ8Mg2ik9IS0LD+GtmxySWB27xPnTLgURL7VLDjjnpAhUzmXgK9bWvgMBr8uA syHwhYVzqc/vcNbJM7QQxnJhV7b+uJ7O8I71zsH6JIiAJnt4aaLZ7BCuuiXgqBapb6mN NEzwGFBwtVdwzZAP3MvCkTHxUiJsCvkHYoQ1NMCGWUz1w1cvWsda+oPUbEAwa8GAc/37 4Cq/gs6iNd+tUGDgwWztfJIJ/lH7BJTr+WIFHeLggNDFCF0KZ9ggyN62trAAbmSU8+My +RPQ== 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=ZFXrx1mroYNZZ+Jm9SMnugMVl5KvJLjmSS+72vS34FY=; b=TJZdfQj8LXbmv46F5p0/l3nsSNRpZtO79mo1NWpM83sxSXvIWmhC+8EjWTfTYCKOGW Q1qNR8C2kKeFkOqTROeSXVJhbL1zyLafkgA6aXuYZ5ljoMzDGugtxSuk79u0tNmfrMc2 hShYTMsQvsiu2NRW8hxus8gySUYeqaJ8uUjkH7N1hqZTVB5wfxQI+MDU6AM9knyFc6VN FD8oyC2yFmDveMWl68XW7zeZ47lwP5fhCs1Ce98OKmC6OnOjm8sa7hs/XWAjZhISDJUA 6XwzsItL0P/rIjVENHqj8MN0R4xRuaRIWT1RAy9V39rkVAG5c+sALrrNO9BDWwPCozPM nLrg== X-Gm-Message-State: APt69E2EQmnV9WmBcZ/nKdCgHPEpemvtl8qZUruBPVnVu9swrspJHlEE AnohbUeh8vaNWQnepso+ouHPVjgglb7anLnd8TY8SQ== X-Google-Smtp-Source: ADUXVKKlcPhHxbP3Mw5DVsyWAGaGoEaGVVTvhSlp1dgWV/fuAVIepu9mSK3SOD4PQ5T5lHSxDCGhh+9Wi2cAyhcHDSU= X-Received: by 2002:a65:42c3:: with SMTP id l3-v6mr105384pgp.398.1529785410368; Sat, 23 Jun 2018 13:23:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:b28c:0:0:0:0 with HTTP; Sat, 23 Jun 2018 13:23:29 -0700 (PDT) In-Reply-To: <010501d40978$b3e609f0$1bb21dd0$@augustcellars.com> References: <01c601d407f8$16621ec0$43265c40$@augustcellars.com> <010501d40978$b3e609f0$1bb21dd0$@augustcellars.com> From: Samuel Erdtman Date: Sat, 23 Jun 2018 22:23:29 +0200 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-oauth-authz@ietf.org, ace Content-Type: multipart/alternative; boundary="000000000000f7ceca056f54ebd6" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz -12 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 23 Jun 2018 20:23:35 -0000 --000000000000f7ceca056f54ebd6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable see inline On Thu, Jun 21, 2018 at 5:58 PM, Jim Schaad wrote: > I sent this review early by accident (I thought I was sending a different > mail). > > > > However a couple things below. > > > > > > *From:* Samuel Erdtman > *Sent:* Thursday, June 21, 2018 8:15 AM > *To:* Jim Schaad > *Cc:* draft-ietf-ace-oauth-authz@ietf.org; ace > *Subject:* Re: [Ace] Review of draft-ietf-ace-oauth-authz -12 > > > > Thanks for reviewing, some answers inline > > > > On Tue, Jun 19, 2018 at 8:05 PM, Jim Schaad > wrote: > > Based on where I currently am, here is another review of the document. > > 1. In section 4 for Figure one: Is the term "RS Information" your term = or > an OAuth term. When I see this I think of it as information for not abou= t > the RS which I do not believe is the intent. > > > > No, the intent is information about the RS for the client. It is describe= d > in "2. Terminology". > > Not sure if "client information" would be preferable. > > > > [JLS] Yeah I agree that =E2=80=98client information=E2=80=99 is not reall= y any better. I > wonder if =E2=80=98Access Information=E2=80=99 might be a better term? > I have create an issue so that it is not forgotten at least. > > > > > > 2. In section 5.1 - I am unclear what the second paragraph is supposed t= o > be doing here. I think that you want state this different. Rather than > talking about the "desired resource" you may want to talk about the AS. > That would better match the title of the section. > > > > The focus could maybe be different but the text is about how to find the > AS but the method for that is quite RS focused. > > > > [JLS] This is not clear to me from what is stated. Does this mean that > there is going to be AS pointers that are contained on the RD entry for t= he > resource that one is interested in? If that is the case then a pointer t= o > where those fields are (going) to be defined would be useful. I read thi= s > as searching the RD for an AS directly. > I did some more reading and I agree the text implies that there is a AS pointer in the RD. I could not find such registration in this document. I have created a github issue to either add this information or remove the text that implies so. > > > > 3. In section 5.1 - There is a note in this section that does not seem t= o > be extremely useful. Where is this discussion go on? Is it still going > on? > I am not even sure if the statement about a common understanding of time = is > correct? It seems that one can either add or not add the nonce as an RS > depending on if you think you understand a common time. > > > > I have not heard anything on the time discussion for a while. > > > > > 4. In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc. Given > the use of POP tokens, what is the reason for this draft and the text abo= ut > client credential types? (Put it this way. I did not need to implement > this for anything yet. Why is it here?) > > > > Not sure what profile you have implemented. > > I-D.erdtman-ace-rpcc defines how the client can use Raw Public Key or Pre > Shared Key with (D)TLS to authenticate it self to the AS. It is not a > strange operation so you might have implemented it without thinking about > it (Ludwig kind of did). I-D.erdtman-ace-rpcc is similar to > draft-ietf-oauth-mtls that defines what was already done in the wild when > it comes to x509 certificates and client authentication. > > Or you might have used default client credentials (client_id/username and > client_secret/password). > > > > I think writing about client credentials is needed since the ACE use case= s > so far has been client centric, i.e. the client is often described to > authenticate as it self to get a token and not as is common i OAuth the > user is authenticated and authorizes the client to get a token. > > With that said the reference to I-D.erdtman-ace-rpcc should maybe be > removed since interest in I-D.erdtman-ace-rpcc has been very limited. > > > > [JLS] I am implementing all of my credentials as being something that is > either a) cooked in to the device or b) as a COSE Key which is part of a > database which is read up by the program. As such I do not believe I am > using anything from this draft. Part of what I am trying to figure out > here is what the status of this document is and what dependencies the Aut= hz > document has one it. Is it really informational? What does it do for th= e > Authz document to have it referenced? Should this document be pushed up = to > a WG document because it is really needed? My understanding from RFC674= 9 > is that these are client credentials that are being used in the HTTP > authentication rather then the TLS client auth layer below HTTP. On the > other hand this is not completely clear. > The draft (erdtman-ace-rpcc) is not concerned about how the key is stored. Id describes how to use the key as a client credential with (D)TLS Raw-Public-Key or Pre-Shared-Key. (depending on the key type). The reference is informational as far as I can tell, it is used to exemplify how the OAuth client authentication can be extended. RFC6749 (The OAuth 2.0 Authorization Framework) describes one type of client credentials and that is (client_id/username and client_secret/password). In my opinion that is not a great fit for the IoT use case with limited user interactions and interfaces. Therefore I created the draft (erdtman-ace-rpcc) to describe how to use Raw-Public-Key or Pre-Shared-Key to authenticate the client, i.e. I think there is value in the document. With that said there is no absolute need for it from draft-ietf-ace-oauth-authz point of view. > > > > > [JLS] These are not finished questions =E2=80=93 not surprised you did no= t respond. > > :-) > > > Jim > > > > Given 15 different introspection tokens, how do I decide which is the one > to > present to the AS - enumerate them? > > 'authorization code' vs 'decode code' grants > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > --000000000000f7ceca056f54ebd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
see inline

On Thu, Jun 21, 2018 at 5:58 PM, Jim Schaad <ietf@augus= tcellars.com> wrote:

I sent this revie= w early by accident (I thought I was sending a different mail).

=C2=A0

However a couple things below.

= =C2=A0

=C2=A0

From: Samuel Erdtman <<= a href=3D"mailto:samuel@erdtman.se" target=3D"_blank">samuel@erdtman.se= >
Sent: Thursday, June 21, 2018 8:15 AM
To: Jim Sch= aad <ietf@au= gustcellars.com>
Cc: draft-ietf-ace-oauth-authz@ietf.or= g; ace <ace@ietf.o= rg>
Subject: Re: [Ace] Review of draft-ietf-ace-oauth-auth= z -12

=C2=A0<= /u>

Thanks for reviewing, some answers= inline

=C2=A0

On Tue, Jun 19, 2018 at 8:05 PM,= Jim Schaad <ietf@augustcellars.com> wrote:

Based on where I currently am, here is another review of the document.
1.=C2=A0 In section 4 for Figure one:=C2=A0 Is the term "RS Info= rmation" your term or
an OAuth term.=C2=A0 When I see this I think = of it as information for not about
the RS which I do not believe is the = intent.

= =C2=A0

No, the intent is inform= ation about the RS for the client. It is described in "2. Terminology&= quot;.

Not = sure if "client information" would be preferable. <= /p>

=C2=A0

[JLS] Yeah I agree that =E2=80=98client information=E2=80=99 is not re= ally any better.=C2=A0 I wonder if =E2=80=98Access Information=E2=80=99 mig= ht be a better term?


I have create an issue so that it is not forgotten = at least.
=C2=A0

=C2=A0=

=C2=A0

=


2.=C2=A0 In section 5.1 - I am unclear what t= he second paragraph is supposed to
be doing here.=C2=A0 I think that you= want state this different.=C2=A0 Rather than
talking about the "de= sired resource" you may want to talk about the AS.
That would bette= r match the title of the section.

=C2=A0

The focus could maybe be different but the text is about how= to find the AS but the method for that is quite RS focused.<= /p>

=C2=A0

[JLS] This is not clear to me from what is stated.=C2=A0 Does this mea= n that there is going to be AS pointers that are contained on the RD entry = for the resource that one is interested in?=C2=A0 If that is the case then = a pointer to where those fields are (going) to be defined would be useful.= =C2=A0 I read this as searching the RD for an AS directly.

<= /div>

I did some mo= re reading and I agree the text implies that there is a AS pointer in the R= D. I could not find such registration in this document.
I have cr= eated a github issue to either add this information or remove the text that= implies so.
=C2=A0

=C2=A0


3.=C2=A0 In se= ction 5.1 - There is a note in this section that does not seem to
be ext= remely useful.=C2=A0 Where is this discussion go on?=C2=A0 Is it still goin= g on?
I am not even sure if the statement about a common understanding o= f time is
correct?=C2=A0 It seems that one can either add or not add the= nonce as an RS
depending on if you think you understand a common time.<= u>

=C2=A0<= /u>

I have not heard anything on the t= ime discussion for a while.

=C2=A0


4.=C2=A0 In secti= on 5.3 - There is a reference to I-D.erdtman-ace-rpcc.=C2=A0 Given
the u= se of POP tokens, what is the reason for this draft and the text about
c= lient credential types?=C2=A0 (Put it this way.=C2=A0 I did not need to imp= lement
this for anything yet.=C2=A0 Why is it here?)

=C2=A0

<= p class=3D"MsoNormal">Not sure what profile you have implemented.=

I-D.erdtman-ace-rpcc defines how = the client can use Raw Public Key or Pre Shared Key with (D)TLS to authenti= cate it self to the AS. It is not a strange operation so you might have imp= lemented it without thinking about it (Ludwig kind of did). I-D.erdtman-ace= -rpcc is similar to draft-ietf-oauth-mtls that defines what was already don= e in the wild when it comes to x509 certificates and client authentication.=

Or you might have used = default client credentials (client_id/username and client_secret/password).=

=C2=A0

I think writing about client credentials= is needed since the ACE use cases so far has been client centric, i.e. the= client is often described to authenticate as it self to get a token and no= t as is common i OAuth the user is authenticated and authorizes the client = to get a token.

With that said the reference to I-D.erdtman-ace-rpcc should maybe be r= emoved since interest in I-D.erdtman-ace-rpcc has been very limited.=

=C2=A0

[JLS] I am implementing all of my credentials as being somet= hing that is either a) cooked in to the device or b) as a COSE Key which is= part of a database which is read up by the program.=C2=A0 As such I do not= believe I am using anything from this draft.=C2=A0 Part of what I am tryin= g to figure out here is what the status of this document is and what depend= encies the Authz document has one it.=C2=A0 Is it really informational?=C2= =A0 What does it do for the Authz document to have it referenced?=C2=A0 Sho= uld this document be pushed up to a WG document because it is really needed= ?=C2=A0=C2=A0 My understanding from RFC6749 is that these are client creden= tials that are being used in the HTTP authentication rather then the TLS cl= ient auth layer below HTTP.=C2=A0=C2=A0 On the other hand this is not compl= etely clear.


The draft (erdtman-ace-rpcc) is not concerned = about how the key is stored. Id describes how to use the key as a client cr= edential with (D)TLS Raw-Public-Key or Pre-Shared-Key. (depending on the ke= y type).
The reference is informational as far as I can tell, it = is used to exemplify how the OAuth client authentication can be extended.
RFC6749 (The OAuth 2.0 Authorization Framework) describes one type= of client credentials and that is (client_id/username and client_sec= ret/password). In my opinion that is not a great fit for the IoT use= case with limited user interactions and interfaces. Therefore I created th= e draft (erdtman-ace-rpcc) to describe how to use Raw-Public-K= ey or Pre-Shared-Key to authenticate the client, i.e. I think there is valu= e in the document.
With that said there is no absolute need f= or it from draft-ietf-ace-oauth-authz point of view.
=C2=A0
<= div class=3D"gmail-m_-4987998402977355176m_2944284566971340146WordSection1"= >

<= /u>

=C2=A0



[JLS] These are not finished questions =E2=80=93 no= t surprised you did not respond.

:-)
<= blockquote style=3D"border-color:currentcolor currentcolor currentcolor rgb= (204,204,204);border-style:none none none solid;border-width:medium medium = medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">

=C2=A0

Jim


Given 15 different introspection tokens, how do I decide which is the one = to
present to the AS - enumerate them?

'authorization code= 9; vs 'decode code' grants


_____________________________= __________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/li= stinfo/ace

=C2=A0


--000000000000f7ceca056f54ebd6-- From nobody Sat Jun 23 14:30:09 2018 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 6CD96130ECB; Sat, 23 Jun 2018 14:30:07 -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 7Ha46HDYQids; Sat, 23 Jun 2018 14:30:05 -0700 (PDT) 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 76018130DD1; Sat, 23 Jun 2018 14:30:05 -0700 (PDT) X-AuditID: 1209190e-3f7ff70000003baa-c2-5b2ebbdbeea4 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 2F.5C.15274.CDBBE2B5; Sat, 23 Jun 2018 17:30:04 -0400 (EDT) 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 w5NLU2Cj022684; Sat, 23 Jun 2018 17:30:02 -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 w5NLTvqX025510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Jun 2018 17:29:59 -0400 Date: Sat, 23 Jun 2018 16:29:57 -0500 From: Benjamin Kaduk To: Mike Jones Cc: Hannes Tschofenig , Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Message-ID: <20180623212956.GE99689@kduck.kaduk.org> References: <20180622204344.GP64617@kduck.kaduk.org> 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+NgFmpjleLIzCtJLcpLzFFi42IR4hRV1r2zWy/a4O1zYYvv33qYLX7+u85s cXPGKSaL1dO/s1nsnfaJxYHVY828NYweG+dMZ/NYsuQnk0frjr/sASxRXDYpqTmZZalF+nYJ XBk3rp9kLljLUfHtxVaWBsarbF2MnBwSAiYSL5tWsnYxcnEICSxmklhzeg2Us5FR4uOdj2wQ zlUmib8/frGCtLAIqErMeP2MHcRmE1CRaOi+zAxiiwjoSDy++A2sgVngK6PEk1mHGEESwgJh Ek8erAWzeYH23Vy9gQVi6j1GiRVTlrFAJAQlTs58AmYzC2hJ3Pj3kqmLkQPIlpZY/o8DJMwp ECvx5s9qsLtFBZQl9vYdYp/AKDALSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st 0jXWy80s0UtNKd3ECA5uSb4djJMavA8xCnAwKvHwfmjVixZiTSwrrsw9xCjJwaQkynuzQida iC8pP6UyI7E4I76oNCe1+BCjBAezkgjv4n6gct6UxMqq1KJ8mJQ0B4uSOG/2IsZoIYH0xJLU 7NTUgtQimKwMB4eSBO+vXUCNgkWp6akVaZk5JQhpJg5OkOE8QMPNdoMMLy5IzC3OTIfIn2JU lBLnXQDSLACSyCjNg+sFJR+J7P01rxjFgV4R5v0EUsUDTFxw3a+ABjMBDb5+SxdkcEkiQkqq gdH+hHeM1jTDfx0XHn7bvVx8+RwPmVL33+XfU/4knrx/v+/jmSaO1t1njyW1CUpqr73wqHhL Sdy3gBCbBFaJ60+DY6ekiJQuOXrQuHHBLtEJ3TskS/suLuOvXHHp4oziad2CHR9lzkzmzGnz eblq39ft3dw2xbt3p3POnCSfJffaylJb+OEvjxYlluKMREMt5qLiRACxOXDRGQMAAA== Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 23 Jun 2018 21:30:08 -0000 On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > See my note just now proposing this text to Jim: > > "Likewise, if PoP keys are used for multiple different kinds of CWTs in an application and the PoP keys are identified by Key IDs, care must be taken to keep the keys for the different kinds of CWTs segregated so that an attacker cannot cause the wrong PoP key to be used by using a valid Key ID for the wrong kind of CWT." > > As long as the PoP keys for different contexts are kept segregated, Key ID collisions or reuse cause no problems. If we trust everyone to implement things properly. We should probably only take that risk if we get some other benefit from it, though. Jim mentioned (off-list?) a scenario involving giving the same client additional privileges, and of course we can gain some simplicity savings if we don't need to enforce global key-id uniqueness (for appropriate values of "global"). So this may well be the right thing to do; I just don't think it's without tradeoffs as your text seems to imply. -Ben From nobody Sun Jun 24 01:15:20 2018 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 5A153130D7A; Sun, 24 Jun 2018 01:15:19 -0700 (PDT) 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] 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 TkTYDIkeJbRS; Sun, 24 Jun 2018 01:15:05 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84CB12F1AB; Sun, 24 Jun 2018 01:14:56 -0700 (PDT) Received: from Jude (151.127.12.101) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 24 Jun 2018 01:11:46 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'Mike Jones' CC: 'Hannes Tschofenig' , , References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> In-Reply-To: <20180623212956.GE99689@kduck.kaduk.org> Date: Sun, 24 Jun 2018 10:14:43 +0200 Message-ID: <027401d40b93$6b73b470$425b1d50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQHH3wOzAp0N2z4AwuijgKMgqXkg Content-Language: en-us X-Originating-IP: [151.127.12.101] Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 24 Jun 2018 08:15:20 -0000 Thinking things through, I would be more comfortable with something like the following: 1. Create a confirmation called 'computed key id'. This has two basic values: What is the computation method? What is the proof value? You can optionally have an unprotected KID value used to filter the set of keys on the RS down to a reasonable set to enumerate (hopefully one). 2. For RPK and TLS: Define a method called hash of SPKI which has a hash method as a parameter. Given that this can be computed independently by all entities based on a Public Key value and it will be unique then you have a key identifier that will not have collisions independent of who issues the CWT. 3. For PSK and TLS: Define a method which takes some parameters including the key value, the CWT issuer identity and perhaps some random string and compute a proof of possession value on the PSK. 4. For PSK and OSCORE: Define a similar method the question would be what the key value is to be used but that can be defined as part of OSCORE When using the keys for TLS For RPK the key is carried in the handshake and the server/client can generate the computed key id and compare it to what the AS distributed. The server can identify which CWTs are applicable by either comparison of the RPKs or the computed key id. This means you have a high probability that you will not make a mistake and match to the wrong key. For PSK the identifier is carried in the handshake which is used to look up a key value and the handshake is performed. By matching computed key ids with the secret value one can ensure to a high probably that only CWTs that reference the same secret are going to be used for permissions even if they come from different AS entities. For OSCORE it is similar, the identifier is used to look up a key value and by decrypting the CWT the key value is proofed. You then match computed key ids in the same manner. If you really want to have something that is not cryptographically computed and point to something else, then it makes more sense to me to reference a CWT issued by the same entity and say "use the same conformation method as this CWT does". jim > -----Original Message----- > From: Benjamin Kaduk > Sent: Saturday, June 23, 2018 11:30 PM > To: Mike Jones > Cc: Hannes Tschofenig ; Jim Schaad > ; draft-ietf-ace-cwt-proof-of-possession@ietf.org; > ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > See my note just now proposing this text to Jim: > > > > "Likewise, if PoP keys are used for multiple different kinds of CWTs in an > application and the PoP keys are identified by Key IDs, care must be taken to > keep the keys for the different kinds of CWTs segregated so that an attacker > cannot cause the wrong PoP key to be used by using a valid Key ID for the > wrong kind of CWT." > > > > As long as the PoP keys for different contexts are kept segregated, Key ID > collisions or reuse cause no problems. > > If we trust everyone to implement things properly. We should probably only > take that risk if we get some other benefit from it, though. Jim mentioned > (off-list?) a scenario involving giving the same client additional privileges, and > of course we can gain some simplicity savings if we don't need to enforce > global key-id uniqueness (for appropriate values of "global"). So this may > well be the right thing to do; I just don't think it's without tradeoffs as your > text seems to imply. > > -Ben From nobody Mon Jun 25 00:24:30 2018 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 34768127598 for ; Mon, 25 Jun 2018 00:24:29 -0700 (PDT) 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 04qo7EURhPNW for ; Mon, 25 Jun 2018 00:24:27 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.43]) (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 E528D124D68 for ; Mon, 25 Jun 2018 00:24:26 -0700 (PDT) Received: from 1fXLrM-000ZOc-V0 by out10c.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fXLrM-000ZRC-Vo for ace@ietf.org; Mon, 25 Jun 2018 00:24:24 -0700 Received: by emcmailer; Mon, 25 Jun 2018 00:24:24 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10c.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fXLrM-000ZOc-V0 for ace@ietf.org; Mon, 25 Jun 2018 00:24:24 -0700 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.1466.3; Mon, 25 Jun 2018 09:24:24 +0200 To: References: From: Ludwig Seitz Message-ID: <6c4cb55d-e350-4389-181f-cf797cdffb00@ri.se> Date: Mon, 25 Jun 2018 09:24:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: 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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 07:24:29 -0000 On 2018-06-22 15:36, Hannes Tschofenig wrote: > Hi Jim, > > I would like to comment on this issue. > > ----- >>> 14. I have real problems w/ the use of a KID for POP identification. It > may >> identify the wrong key or, if used for granting access, may have problems > w/ >> identity collisions. These need to be spelt out someplace to help people >> tracking down questions of why can't I verify w/ this CWT, I know it's > right. I just wanted to note that we inherited that issue from RFC 7800, does someone recall what the security considerations were in that case? Perhaps a variant of Hannes' text comes closer to what Jim is looking for: " - Operational Considerations ... When an issuer creates a CWT containing a key id claim, it is not acceptable to issue another CWT containing the same key id, unless they both are for the same subject and for the same audience (e.g. providing additional privileges for the subject). " /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Jun 25 01:25:55 2018 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 CB12B130E97 for ; Mon, 25 Jun 2018 01:25:54 -0700 (PDT) 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 v3807wL0zsO8 for ; Mon, 25 Jun 2018 01:25:52 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.40]) (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 870941277C8 for ; Mon, 25 Jun 2018 01:25:52 -0700 (PDT) Received: from 1fXMon-000Hcx-UI by out10d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fXMon-000Heh-VK for ace@ietf.org; Mon, 25 Jun 2018 01:25:49 -0700 Received: by emcmailer; Mon, 25 Jun 2018 01:25:49 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fXMon-000Hcx-UI for ace@ietf.org; Mon, 25 Jun 2018 01:25:49 -0700 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.1466.3; Mon, 25 Jun 2018 10:25:49 +0200 To: ace References: <01c601d407f8$16621ec0$43265c40$@augustcellars.com> <010501d40978$b3e609f0$1bb21dd0$@augustcellars.com> From: Ludwig Seitz Message-ID: <9f0ae26c-5b7f-b9d9-4ac7-3583236f5d17@ri.se> Date: Mon, 25 Jun 2018 10:25:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: 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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz -12 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 08:25:55 -0000 > 3. In section 5.1 - There is a note in this section that does > not seem to > be extremely useful. Where is this discussion go on? Is it > still going on? > I am not even sure if the statement about a common understanding > of time is > correct? It seems that one can either add or not add the nonce > as an RS > depending on if you think you understand a common time. I agree, this seems like a leftover from when we discussed the issue of common understanding of time. I suggest we remove that paragraph. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Jun 25 02:48:31 2018 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 0B0881277C8; Mon, 25 Jun 2018 02:48:25 -0700 (PDT) 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.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152992010496.6352.4504422942099662964@ietfa.amsl.com> Date: Mon, 25 Jun 2018 02:48:25 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 09:48:25 -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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Sandeep S. Kumar Michael C. Richardson Martin Furuhed Shahid Raza Filename : draft-ietf-ace-coap-est-03.txt Pages : 39 Date : 2018-06-25 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows low-resource constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-03 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-03 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 Jun 25 04:34:59 2018 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 281EA130E6F for ; Mon, 25 Jun 2018 04:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 3d8Zc7ReW61s for ; Mon, 25 Jun 2018 04:34:55 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65EA1130E22 for ; Mon, 25 Jun 2018 04:34:55 -0700 (PDT) Received: from Jude (151.127.12.101) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 25 Jun 2018 04:31:44 -0700 From: Jim Schaad To: Date: Mon, 25 Jun 2018 13:34:42 +0200 Message-ID: <001701d40c78$84d0c3f0$8e724bd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdQMeEd3l2ZiQbv0TSqaYFIcJkparw== X-Originating-IP: [151.127.12.101] Archived-At: Subject: [Ace] Early registration of CoAP Media types for draft-ietf-ace-coap-est X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 11:34:57 -0000 We have received a request for early registration approval for the media types in draft-ietf-ace-coap-est. As part of the input to the decision to do this we need to know if there are any people who object to proceeding. If you object please respond either to the list or to the chairs and provide the reasons why you believe that this early registration should not proceed. The chairs will make the decision before the Montreal IETF. Jim From nobody Mon Jun 25 04:35:48 2018 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 44A87130E71 for ; Mon, 25 Jun 2018 04:35:46 -0700 (PDT) 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 gMWUdKEDijd5 for ; Mon, 25 Jun 2018 04:35:45 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D816130E6F for ; Mon, 25 Jun 2018 04:35:45 -0700 (PDT) Received: from Jude (151.127.12.101) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 25 Jun 2018 04:32:38 -0700 From: Jim Schaad To: Date: Mon, 25 Jun 2018 13:35:37 +0200 Message-ID: <001801d40c78$a4a1c120$ede54360$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdQMeIgIwlMdv/vVQG6WAi74uc5Vzg== X-Originating-IP: [151.127.12.101] Archived-At: Subject: [Ace] Montreal IETF Agenda X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 11:35:47 -0000 If you want a spot on the agenda please let the chairs know. Please include topic/draft, presenter and a time request. Jim From nobody Mon Jun 25 04:38:02 2018 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 0B903130E6F for ; Mon, 25 Jun 2018 04:38:00 -0700 (PDT) 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 PrBu8z5X4cBA for ; Mon, 25 Jun 2018 04:37:57 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.43]) (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 9EF77130DD1 for ; Mon, 25 Jun 2018 04:37:57 -0700 (PDT) Received: from 1fXPoh-000XZU-TQ by out11b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fXPoh-000Xae-UE for ace@ietf.org; Mon, 25 Jun 2018 04:37:55 -0700 Received: by emcmailer; Mon, 25 Jun 2018 04:37:55 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fXPoh-000XZU-TQ for ace@ietf.org; Mon, 25 Jun 2018 04:37:55 -0700 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.1466.3; Mon, 25 Jun 2018 13:37:54 +0200 To: References: <001801d40c78$a4a1c120$ede54360$@augustcellars.com> From: Ludwig Seitz Message-ID: Date: Mon, 25 Jun 2018 13:37:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <001801d40c78$a4a1c120$ede54360$@augustcellars.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-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] Montreal IETF Agenda X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 11:38:01 -0000 On 2018-06-25 13:35, Jim Schaad wrote: > If you want a spot on the agenda please let the chairs know. > > Please include topic/draft, presenter and a time request. > > Jim > Hello, I'd like a 10 min. slot to present changes to draft-ietf-ace-oauth-authz and the results of the interop(s). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Jun 25 06:36:43 2018 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 40537130DE9 for ; Mon, 25 Jun 2018 06:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 U2MF_GATiANC for ; Mon, 25 Jun 2018 06:36:38 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0093.outbound.protection.outlook.com [104.47.42.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F18B124D68 for ; Mon, 25 Jun 2018 06:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZJoZtT9aCkdm6BURwiM0s+5yT6Yh4TVUcgdiUyHSNXM=; b=Jf4bRIYhZj+8fCvbsc1BH7rYCr2XUmWmxw/IHCJalDaMFYjHFU3djaM30pn6Qhdt0WHdlmqj/5GZYWFS1mDF3MAKmdKQf76tbl7bPsLdrlGGc6aAnZ8j6pjaMXXLyT8lj09WLmTaqdfNFv1qlNbM9f01qG6aF6GZZE9uDjoU09I= Received: from SN6PR00MB0301.namprd00.prod.outlook.com (52.132.117.155) by SN6PR00MB0349.namprd00.prod.outlook.com (52.132.118.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.941.0; Mon, 25 Jun 2018 13:36:37 +0000 Received: from SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::1835:2a6b:5366:6133]) by SN6PR00MB0301.namprd00.prod.outlook.com ([fe80::1835:2a6b:5366:6133%5]) with mapi id 15.20.0943.000; Mon, 25 Jun 2018 13:36:37 +0000 From: Mike Jones To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Montreal IETF Agenda Thread-Index: AdQMeIgIwlMdv/vVQG6WAi74uc5VzgAENL7g Date: Mon, 25 Jun 2018 13:36:36 +0000 Message-ID: References: <001801d40c78$a4a1c120$ede54360$@augustcellars.com> In-Reply-To: <001801d40c78$a4a1c120$ede54360$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.251.121.244] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0349; 7:EMeEELOg/p/NWGOc91Gg3I+WJwUBzms/BTN1k5C/+AsdYyIhVvc6fhPYqROyNMn8XdkXQlRMsPHniCEe9JQBPmELYtynHmA17JWgWxfrCuZgjgSgvYZs2cRoV8oRvCLaSRam4jDiVOQlmuBWHnpWwIM694OJVgM23aa7jvtRT+9nK/WI9A/ZxLV5/uqgVvfh1Rh/oOrr0ytHXZ+4lH5Y0P795cwJQ8HLpNQeSLL1cTjRMZl5ClsdV1IwXn0bVLSt x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f3561469-c6b6-4514-28d2-08d5daa0acba x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:SN6PR00MB0349; x-ms-traffictypediagnostic: SN6PR00MB0349: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(93006095)(93001095)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0349; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0349; x-forefront-prvs: 0714841678 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(396003)(39860400002)(39380400002)(199004)(189003)(13464003)(97736004)(25786009)(5250100002)(14454004)(3846002)(2906002)(72206003)(2501003)(478600001)(7736002)(110136005)(966005)(74316002)(305945005)(22452003)(6116002)(316002)(3280700002)(99286004)(10290500003)(81156014)(81166006)(8936002)(8676002)(6306002)(9686003)(55016002)(6436002)(3660700001)(6246003)(86362001)(8990500004)(229853002)(105586002)(5660300001)(2900100001)(86612001)(106356001)(68736007)(10090500001)(33656002)(486006)(476003)(26005)(7696005)(446003)(53546011)(6506007)(11346002)(76176011)(102836004)(59450400001)(53936002)(66066001)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0349; H:SN6PR00MB0301.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: kehwoTSP4w03arD+Kq64N6+LNy2Wj/M8/VTBW6JVP2WinlyQ7tLtXwwsWXceIHQKNJ48U8dBRx7bouyonQC8q8U8Oih4yMCOsXHvTga9SKhAVPZVIvDZ0kziRxoPT/x2mwUOsZebDEfeuAoiGAegPSH3hHkZ25lRtRU8PFztRNQrE1NysW5xJ7lS1caaLNlqyUxqgpxmj8eKAihs45RHU7jXeIbkN5Cx8cl8haUhC4rVG0ucivNznlWwVUjDrOpO47wYdJ29kOCad8U2mBQ16bLxEoKFUovLNyZxhnyTYTYp5SVXktUgqRsTYYAr77GfEq3KNnwP7k47ZpfR8b+GbwKSBqqvqhWdN5JwtsK+lZE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f3561469-c6b6-4514-28d2-08d5daa0acba X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2018 13:36:36.8545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0349 Archived-At: Subject: Re: [Ace] Montreal IETF Agenda X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 13:36:42 -0000 I'd like 15 minutes to discuss draft-ietf-ace-cwt-proof-of-possession. Thanks, -- Mike -----Original Message----- From: Ace On Behalf Of Jim Schaad Sent: Monday, June 25, 2018 4:36 AM To: ace@ietf.org Subject: [Ace] Montreal IETF Agenda If you want a spot on the agenda please let the chairs know. Please include topic/draft, presenter and a time request. Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jun 25 06:53:30 2018 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 7A8E4130E97 for ; Mon, 25 Jun 2018 06:53:28 -0700 (PDT) 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] 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 Tu4lLImU8pbb for ; Mon, 25 Jun 2018 06:53:25 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0244.hostedemail.com [216.40.44.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC548124C04 for ; Mon, 25 Jun 2018 06:53:25 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 7956018225B1E; Mon, 25 Jun 2018 13:53:24 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:41:72:152:355:379:582:599:800:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1534:1541:1561:1575:1588:1589:1592:1594:1711:1714:1730:1777:1792:2068:2069:2198:2199:2525:2528:2559:2564:2682:2685:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3622:3865:3867:3868:3873:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4860:5007:6117:6261:6657:6678:7875:7903:7974:8603:9010:9025:9177:10004:10214:10400:10848:11232:11658:11914:12043:12291:12379:12438:12683:12740:12895:13071:13139:13439:13846:14095:14096:14110:14180:14181:14721:21060:21063:21080:21433:21451:21627:30054:30060, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:26, LUA_SUMMARY:none X-HE-Tag: fire04_75073b91e0a44 X-Filterd-Recvd-Size: 2729 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf03.hostedemail.com (Postfix) with ESMTPA; Mon, 25 Jun 2018 13:53:24 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7264be78235160a82140e79ab09a04d9" Date: Mon, 25 Jun 2018 15:53:23 +0200 From: Peter van der Stok To: Jim Schaad Cc: ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <001801d40c78$a4a1c120$ede54360$@augustcellars.com> References: <001801d40c78$a4a1c120$ede54360$@augustcellars.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.250.16] Archived-At: Subject: Re: [Ace] Montreal IETF Agenda X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 13:53:29 -0000 --=_7264be78235160a82140e79ab09a04d9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII HI Jim, I like 10-15 mins to discuss est-coaps, - discuss delayed response, - open points, Peter Jim Schaad schreef op 2018-06-25 13:35: > If you want a spot on the agenda please let the chairs know. > > Please include topic/draft, presenter and a time request. > > Jim > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=_7264be78235160a82140e79ab09a04d9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Jim,

I like 10-15 mins to discuss est-coaps,
- discuss d= elayed response,
- open points,

Peter

Jim Schaad schreef op 2018-06-25 13:35:

= If you want a spot on the agenda please let the chairs know.

Pl= ease include topic/draft, presenter and a time request.

Jim


_______________________________________________
Ace ma= iling list
Ace@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/ace
--=_7264be78235160a82140e79ab09a04d9-- From nobody Mon Jun 25 18:54:57 2018 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 6EA89130F47 for ; Mon, 25 Jun 2018 18:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 (1024-bit key) header.d=cert.org 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 Q6YtbbHJDQUf for ; Mon, 25 Jun 2018 18:54:50 -0700 (PDT) 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 C53E7130E7A for ; Mon, 25 Jun 2018 18:54:50 -0700 (PDT) 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 w5Q1sYlf029384; Mon, 25 Jun 2018 21:54:34 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w5Q1sYlf029384 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1529978074; bh=YeyK9Vy11geO62T/JkOy1ID7K4WIG/Lpqrot17iUAdY=; h=From:To:Subject:Date:References:In-Reply-To:From; b=A/183994UbuMEI0unkOAscogfUYzphuxwZcW8b4wlF6lmkdae0c2tXWRmdy87lJ4/ DpzMzxI5NmHizuTeK+iKEKIx/YPF3tuL4eydNBA9ci9VEkFNpH5I2QT/2EfCiJ1RiU 2aOT+g38HwUs7f2pZAf4VWCBt2ObYeHsOA96LzSs= 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 w5Q1sWXY012277; Mon, 25 Jun 2018 21:54:32 -0400 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.0399.000; Mon, 25 Jun 2018 21:54:32 -0400 From: Roman Danyliw To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdQJ/3hMPxiML8tzRZiI8rJseWPrOAC8HqIQ Date: Tue, 26 Jun 2018 01:54:31 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C3F3BCC@marathon> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 01:54:56 -0000 Hi Hannes! > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com] > Sent: Friday, June 22, 2018 9:36 AM > To: Roman Danyliw ; ace@ietf.org > Subject: "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proo= f-of- > possession-02 >=20 > Hi Roman, >=20 > this is also a good question: >=20 > > (3) (Editorial) Page 4, Section 3.0, I read to the end of this section = by which > point there has been discussion of "sub" or "iss". I was left wondering = about > how to interpret the case where both are present and none are. >=20 > Here is the text from the draft: >=20 > " > The presenter can be identified in one of several ways by the CWT > depending upon the application requirements. If the CWT contains a > "sub" (subject) claim [CWT], the presenter is normally the subject > identified by the CWT. (In some applications, the subject identifier > will be relative to the issuer identified by the "iss" (issuer) claim > [CWT].) If the CWT contains no "sub" claim, the presenter is > normally the issuer identified by the CWT using the "iss" claim. The > case in which the presenter is the subject of the CWT is analogous to > Security Assertion Markup Language (SAML) 2.0 > [OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one of > the "sub" and "iss" claims is typically present in the CWT and some > use cases may require that both be present. > " >=20 > The CWT PoP document does not define the subject or issuer claims. > The document also not mandate a specific set of claims to be included in = a > CWT since this is application profile specific. >=20 > Hence, I am wondering whether we could shorten the paragraph above, > which is actually a bit confusing. >=20 > " > This specification adds a new claim to offer the proof-of-possession > functionality. > There are various claims already defined and the IANA claims registry [RE= F] > contains the most up-to-date list of standardized claims. Application usi= ng > the CWT functionality define what claims have to be used. >=20 > The presenter can, if necessary, be identified in one of several ways b= y the > CWT > depending upon the application requirements. If the CWT contains a > "sub" (subject) claim [CWT], the presenter is the subject > identified by the CWT. In some cases, there CWT may not include a "sub= " > claim, which allows the presenter to remain anonymous. > " I like this shortened paragraph proposed above. IMO, it's simpler and more= appropriate in this draft. Thanks, Roman > Ciao > Hannes >=20 > 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. From nobody Mon Jun 25 18:57:14 2018 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 83661130F47 for ; Mon, 25 Jun 2018 18:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 (1024-bit key) header.d=cert.org 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 DX2e9BLHY9FQ for ; Mon, 25 Jun 2018 18:57:06 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 CC8BD130E7A for ; Mon, 25 Jun 2018 18:57:05 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w5Q1uxoi014841; Mon, 25 Jun 2018 21:56:59 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w5Q1uxoi014841 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1529978219; bh=MMYrjM0fCGXP2ooQWkHC+nqAYC+x2ObqxGyGCMBctQ8=; h=From:To:Subject:Date:References:In-Reply-To:From; b=BwMh8XH9RrvNTgECofoWV2Bv0DNq0OEVRf9mx2xUi50WuMAN2cdWv4ZkCcszCGMNc 5RuFrAeAwBMzt8CbtExuWH+prxkvVLV1az6UNSNyCD/0i7wQtaBiI7/5wXPadOsRLK 5vwL7X7HA3vd/m/zRImpUvaMoeALVsaIVPatVQ90= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w5Q1uuG9037313; Mon, 25 Jun 2018 21:56:56 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0399.000; Mon, 25 Jun 2018 21:56:56 -0400 From: Roman Danyliw To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AdQJ+lWc2W0LPLoES1iMKd72DvNSVQC9mhKQ Date: Tue, 26 Jun 2018 01:56:55 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C3F3C1F@marathon> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 01:57:11 -0000 Hi Hannes! > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com] > Sent: Friday, June 22, 2018 9:36 AM > To: Roman Danyliw ; ace@ietf.org > Subject: Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of- > possession-02 >=20 > Hi Roman, >=20 > Thanks for your review. >=20 > As I was re-reading the reviews I spotted this comment: >=20 > > (14) (Editorial) Page 8, Section 4, Per "Replay can also be avoided i= f a sub- > key is derived from a shared secret that is specific to the instance of t= he PoP > demonstration." PoP is spelled out everywhere else in this draft but her= e. > Yes, the acronym is defined, but for readability, I recommend against it = using > it and consistently spelling it out here too. >=20 > I believe the current text is a bit confusing. Here is what it says: >=20 > Proof of possession via encrypted symmetric secrets is subject to replay > attacks. > This attack can, for example, be avoided when a signed nonce or challenge= is > used since the recipient can use a distinct nonce or challenge for each > interaction. > Replay can also be avoided if a sub-key is derived from a shared secret t= hat is > specific to the instance of the proof-of-possession demonstration. >=20 > This somehow gives the impression that replay attacks are only a concern = for > symmetric key techniques. > Of course, this is not true. Furthermore, the text gives the impression t= hat > this attack is actually something that can be covered within the CWT-PoP > token spec itself. This is also not the case. >=20 > For this reason I am suggesting to change the paragraph to: > " > CBOR Web Tokens with proof-of-possession keys are used in context of an > architecture, such as ACE-OAuth [REF], where protocols are used by a > presenter to request these tokens and to subsequently use them with > recipients. To avoid replay attacks when the proof-of-possession tokens a= re > sent to presenters a security protocol, which uses nonces or timestamps, = has > to be utilized. > Note that a discussion of the architecture or specific protocols CWT proo= f-of- > possession tokens are used with are outside the scope of this specificati= on. " This new paragraph is easier to understand. It addresses my feedback.=20 Thanks, Roman > Ciao > Hannes >=20 > 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. From nobody Tue Jun 26 01:54:09 2018 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 7425D130E92; Tue, 26 Jun 2018 01:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 VkFtnGqjJ0bM; Tue, 26 Jun 2018 01:54:05 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0069.outbound.protection.outlook.com [104.47.1.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 9BD63130EC0; Tue, 26 Jun 2018 01:54:04 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=TXiIBQuEnvgQS6QKn4ebkZxTnViVmG3ioEFA6TjB5fM=; b=iMrg+nQxaZKwnHh+hBkhCd3DIs9pff2x5RTa3/tsPVgP0IZwNhmv98gwXirkRGubj1AIUYlG4xCEeynVea0gUGsp2vgHVpZXLPaAJCoaUDocHm09wYa/WrmwS0RIvNN+1/8cF7+pITmaCrEfnD5vZkTh9a0fvWqQr9hViUyBsck= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1535.eurprd08.prod.outlook.com (10.167.210.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.24; Tue, 26 Jun 2018 08:53:57 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%9]) with mapi id 15.20.0884.024; Tue, 26 Jun 2018 08:53:57 +0000 From: Hannes Tschofenig To: Benjamin Kaduk , Mike Jones CC: Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AQHUCmm7VfkGifo3LEWkTqcB1vlZy6Rsv/OAgAGd44CAA+LVoA== Date: Tue, 26 Jun 2018 08:53:57 +0000 Message-ID: References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> In-Reply-To: <20180623212956.GE99689@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.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1535; 7:OAeUjJlez9mXlIcBMcrNueRk9SpxjQAUw3J0+7LFvzDKrOzHEWjwgJHqFqCkYIHJDquRyM07EJmOJTOXIwQhBgx3/hojwINl2/lRZWGRR6gKlf13K8Clty5qUQxG5xyMLLJLuKFVrEyiwgR+BKD0hrSyT9Z1MjYAzJONYmXcKKE0o1l889GdsVbcDl5vlkskEcWKKcAmmUiz3YnW7iWNanQuTNXknA9nd/qexY9jocfaGCWPrZmtCKmYzuTXtHJx x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f1e21085-99c8-45c6-7ef6-08d5db425a68 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1535; x-ms-traffictypediagnostic: VI1PR0801MB1535: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(223705240517415)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231254)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1535; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1535; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39860400002)(136003)(366004)(13464003)(189003)(199004)(40434004)(3846002)(8936002)(74316002)(6116002)(8676002)(7736002)(305945005)(81166006)(68736007)(14454004)(81156014)(105586002)(476003)(33656002)(11346002)(446003)(486006)(106356001)(5660300001)(2906002)(6246003)(53936002)(2171002)(55016002)(9686003)(53546011)(2900100001)(4326008)(186003)(54906003)(93886005)(25786009)(102836004)(478600001)(5250100002)(6436002)(6506007)(26005)(229853002)(86362001)(66066001)(316002)(97736004)(72206003)(1511001)(76176011)(99286004)(110136005)(7696005)(5024004)(14444005)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1535; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LnQc6HzushUg5bKgblgfQf5uC/VWRryUqS194U23dqUeeu1Pv2hpuq+2yOKkMUO3SJkcyjq1YAnfWUaLFrwKpbjMUolsMc3rYgGoNwRghDmGaPC52kTfJWMxf9u/EPAyRuDC0NMs1hUCF1STACafbZkp/nyUQYE/9XzDAMgESTLopjPGlqST9lvBSCyGFSx20Mp6Vjhco5zLLdhVc4vkQ7bz6Rl+8DallCgsp9d6wACWsomZIR6ZAPsBHjmEjTiN3dpx8/P4sMc13SRGqQIGSQXX2hEYDSOPRVU3PNgC/7udnheYFX+HvrgsFIGLuzwpXkyZUI4J28T6/ayE/pSA0CwF/c37djCrFL72s8BaYcs= 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: f1e21085-99c8-45c6-7ef6-08d5db425a68 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 08:53:57.2509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1535 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 08:54:08 -0000 Ben, I was wondering whether the situation is any different in Kerberos. If the = KDC creates tickets with a session key included then it needs to make sure = that it does not create the same symmetric key for different usages. The key in the Kerberos ticket is similar to the PoP key in our discussion. Are we aware of key collision in Kerberos? Ciao Hannes -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@mit.edu] Sent: 23 June 2018 23:30 To: Mike Jones Cc: Hannes Tschofenig; Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@i= etf.org; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-poss= ession-02 On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > See my note just now proposing this text to Jim: > > "Likewise, if PoP keys are used for multiple different kinds of CWTs in a= n application and the PoP keys are identified by Key IDs, care must be take= n to keep the keys for the different kinds of CWTs segregated so that an at= tacker cannot cause the wrong PoP key to be used by using a valid Key ID fo= r the wrong kind of CWT." > > As long as the PoP keys for different contexts are kept segregated, Key I= D collisions or reuse cause no problems. If we trust everyone to implement things properly. We should probably only take that risk if we get some other benefit from it, though. Jim mentioned (off-list?) a scenario involving giving the same client additional privileges, and of course we can gain some simplicity savings if we don't need to enforce global key-id uniqueness (for appropriate values of "global"). So this may well be the right thing to do; I just don't think it's without tradeoffs as your text seems to imply. -Ben 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 Jun 26 08:00:15 2018 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 9849313103A; Tue, 26 Jun 2018 08:00:13 -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 XQfftgDH8Owx; Tue, 26 Jun 2018 08:00:11 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 4F670130EF6; Tue, 26 Jun 2018 08:00:11 -0700 (PDT) X-AuditID: 12074424-47bff70000002ba7-a0-5b3254faf40f 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id EC.4B.11175.AF4523B5; Tue, 26 Jun 2018 11:00:10 -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 w5QF085w000414; Tue, 26 Jun 2018 11:00:09 -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 w5QF04Oe014000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jun 2018 11:00:06 -0400 Date: Tue, 26 Jun 2018 10:00:04 -0500 From: Benjamin Kaduk To: Hannes Tschofenig Cc: Mike Jones , Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Message-ID: <20180626150003.GD79565@kduck.kaduk.org> References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> 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+NgFmphleLIzCtJLcpLzFFi42IRYrdT1/0VYhRt0PRXzOL7tx5mi5//rjNb 3Jxxisli9fTvbBZ7p31icWD1WDNvDaPHxjnT2TyWLPnJ5NG64y97AEsUl01Kak5mWWqRvl0C V8aRU7+ZC6ZwVDSdW8PawHiUrYuRk0NCwERi1+rrzCC2kMBiJolTe3y6GLmA7I2MEhP3PmSC cK4ySUx+/BmoioODRUBV4veGVJAGNgEViYbuy2DNIgKGEnubD7GC1DMLfGCUuLDhJgtIQlgg TOLJg7WMIDYv0LZzf+5ADX3AJLFuwnKohKDEyZlPwBqYBbQkbvx7yQSyjFlAWmL5Pw6QMKdA osSd/0fArhYVUJbY23eIfQKjwCwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI 11wvN7NELzWldBMjOLBdVHYwdvd4H2IU4GBU4uG9YW8ULcSaWFZcmXuIUZKDSUmU94MzUIgv KT+lMiOxOCO+qDQntfgQowQHs5II77G3htFCvCmJlVWpRfkwKWkOFiVx3txFjNFCAumJJanZ qakFqUUwWRkODiUJXl1gBAsJFqWmp1akZeaUIKSZODhBhvMADbcAqeEtLkjMLc5Mh8ifYlSU Euc9GwSUEABJZJTmwfWCEo9E9v6aV4ziQK8I8zKDtPMAkxZc9yugwUxAg8seG4AMLklESEk1 MB5ImbfcyYlL81fXak+LxxZPz18/w3n6yaTQQybet95oHTYOtDvks+Xu7d1Ofz97f14udSKG s9imkDOa6ddhpz9fXrGuXpi3ykyySru4fV5Wj5fhjYvmjWuM1vIUP8/NzN/yzJGt3bXSoutx k/KWj2eFdH2cfH/vXb5MPXWxwbYXs2/Y/lzEM0eJpTgj0VCLuag4EQAcW9IBFwMAAA== Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 15:00:14 -0000 On Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote: > Ben, > > I was wondering whether the situation is any different in Kerberos. If the KDC creates tickets with a session key included then it needs to make sure that it does not create the same symmetric key for different usages. > The key in the Kerberos ticket is similar to the PoP key in our discussion. > > Are we aware of key collision in Kerberos? I don't believe key collision is an issue in Kerberos. Long-term keys (which are not what we're talking about here) are identified by a principal name, encryption type, and version number. Session keys that are contained within tickets (and returned to the client in the KDC-REP) are random, so even if we are only using the birthday bound we're still in pretty good shape. The modern enctypes tend to use subsession keys generated by the client and/or server as well as the KDC-generated session key, which provides further binding to the current session. Does that answer your question? -Ben From nobody Tue Jun 26 08:13:04 2018 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 72379130ED9; Tue, 26 Jun 2018 08:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 yaJqgqzL7vCH; Tue, 26 Jun 2018 08:12:56 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on061a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::61a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85984130E84; Tue, 26 Jun 2018 08:12:55 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=U9Y/n/VtjFcUlDGmYGqwXwM6bFPJmn/eSYyACDx5jEA=; b=eMQ1wal8egfMO0Xe+gzummtKJuLSfBoUIoAqA61AMp3TUjdHhLepvirkfsDDBAe0MfoJ9aadZpZEcdxg/IHl0sbrVz7ITxZaV9XH7eiB0B25bsgjFDLuLUPPKhz4cvoK0m4q06/fFz5KW9ySFpJ96iZJA3BrKHJN/3CMJ8Xo8GA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1486.eurprd08.prod.outlook.com (10.167.210.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.21; Tue, 26 Jun 2018 15:12:52 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%9]) with mapi id 15.20.0884.024; Tue, 26 Jun 2018 15:12:52 +0000 From: Hannes Tschofenig To: Benjamin Kaduk CC: Mike Jones , Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AQHUCmm7VfkGifo3LEWkTqcB1vlZy6Rsv/OAgAGd44CAA+LVoIAAZzsAgAADOlA= Date: Tue, 26 Jun 2018 15:12:52 +0000 Message-ID: References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <20180626150003.GD79565@kduck.kaduk.org> In-Reply-To: <20180626150003.GD79565@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.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1486; 7:5edgxC/hCasGZ7dfCdOpDevZmX4MJIYmv8U7O3JquAllV7c2HVg1crnZorx9ruXBuc/Nbt2WnoTZdCRz4l1nQpxF1KhPfWAjoNhgLG6meDocmfLDy5624OFxZ7mIjwokZdbB69mcm1+ubuqX/Q8Mz74AI45hokDnX4QciilO4o1VmlS9GORa+s3c3ka8lVZaZclppPnYaOqXa4w9Fv5EwaV/9aVeX+mj7pa8jD0dwq8jyao6HE+nIABhZJd0gVaJ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 46e31fd5-c313-4579-38f5-08d5db7749b6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1486; x-ms-traffictypediagnostic: VI1PR0801MB1486: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(223705240517415)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1486; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1486; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(346002)(136003)(366004)(13464003)(199004)(40434004)(189003)(3846002)(33656002)(6246003)(54906003)(305945005)(316002)(2906002)(7736002)(8936002)(4326008)(8676002)(105586002)(81166006)(81156014)(74316002)(93886005)(11346002)(486006)(5024004)(6116002)(476003)(14444005)(106356001)(186003)(446003)(256004)(2900100001)(53936002)(2171002)(25786009)(478600001)(53546011)(97736004)(14454004)(76176011)(6436002)(9686003)(229853002)(5660300001)(55016002)(6916009)(68736007)(7696005)(86362001)(102836004)(5250100002)(66066001)(6506007)(26005)(99286004)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1486; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: go4+RifOJj3EMyqtpw319kaGmJVsutuHVQWkH29LX8HkJDqaQsOGKxml4hVuXNOvJd6/l52YK+8j9bZYQpSS2xOuZocpGOJuVlfismf5veIXLXMmSUyeMIctl8KM9Z3dqLqI17V+wBLewvdXqRzUF+AiDwV7Iqd8BIUfX9L+TPwY76OhQx/lWykMFcf56MNKRYDqA8/DX0PtkeBab+bBEC1nT6PCaAM2AObGaDomh6Llt2rhKDTX+VCYzP7Kqd5gmGFbjuIAhVLMDROKpv2Un0UAzx2qnVFyMx6HVkHbeZLKn32upKY8ZKdyGTtzXXXSvVPQIouKZ63Nilt5lr75dc10qx2WoRIeJOmBmS7++/c= 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: 46e31fd5-c313-4579-38f5-08d5db7749b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 15:12:52.6282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1486 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 15:13:01 -0000 It does answer my question, Ben. This begs the question why the collision of session keys is suddenly a prob= lem in the ACE context when it wasn't a problem so far. Something must have= changed. Ciao Hannes -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@mit.edu] Sent: 26 June 2018 17:00 To: Hannes Tschofenig Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.org= ; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-poss= ession-02 On Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote: > Ben, > > I was wondering whether the situation is any different in Kerberos. If th= e KDC creates tickets with a session key included then it needs to make sur= e that it does not create the same symmetric key for different usages. > The key in the Kerberos ticket is similar to the PoP key in our discussio= n. > > Are we aware of key collision in Kerberos? I don't believe key collision is an issue in Kerberos. Long-term keys (which are not what we're talking about here) are identified by a principal name, encryption type, and version number. Session keys that are contained within tickets (and returned to the client in the KDC-REP) are random, so even if we are only using the birthday bound we're still in pretty good shape. The modern enctypes tend to use subsession keys generated by the client and/or server as well as the KDC-generated session key, which provides further binding to the current session. Does that answer your question? -Ben 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 Jun 26 08:14:27 2018 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 11238130E8E; Tue, 26 Jun 2018 08:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 RqQtABxHbgPF; Tue, 26 Jun 2018 08:14:24 -0700 (PDT) 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 0D731130DFD; Tue, 26 Jun 2018 08:14:23 -0700 (PDT) X-AuditID: 1209190e-a39ff700000072da-fc-5b32584ed4f4 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 44.9D.29402.E48523B5; Tue, 26 Jun 2018 11:14:22 -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 w5QFEKdR029869; Tue, 26 Jun 2018 11:14:21 -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 w5QFEGnf018836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jun 2018 11:14:18 -0400 Date: Tue, 26 Jun 2018 10:14:16 -0500 From: Benjamin Kaduk To: Hannes Tschofenig Cc: Mike Jones , Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Message-ID: <20180626151415.GE79565@kduck.kaduk.org> References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <20180626150003.GD79565@kduck.kaduk.org> 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+NgFupnleLIzCtJLcpLzFFi42IR4hTV1vWLMIo2OPPLyuL7tx5mi5//rjNb 3Jxxisli9fTvbBZ7p31icWD1WDNvDaPHxjnT2TyWLPnJ5NG64y97AEsUl01Kak5mWWqRvl0C V8bZjq1MBZsFK56dz25g/MvbxcjBISFgIvF2dmYXIxeHkMBiJolZhz+wQTgbGSVOfdrMCOFc ZZI4NfsEexcjJweLgKrEpoW72EBsNgEViYbuy8wgtoiAocTe5kOsIA3MAh8YJS5suMkCkhAW CJN48mAtI4jNC7Tu/+fL7BBTHzFL3DqzkxkiIShxcuYTsAZmAS2JG/9eMoHcxywgLbH8HweI ySmQKNG+KxWkQlRAWWJv3yH2CYwCs5A0z0LSPAuheQEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy8 1CJdY73czBK91JTSTYzgsJbk28E4qcH7EKMAB6MSD6+Bk1G0EGtiWXFl7iFGSQ4mJVHeD85A Ib6k/JTKjMTijPii0pzU4kOMEhzMSiK8x94aRgvxpiRWVqUW5cOkpDlYlMR5sxcxRgsJpCeW pGanphakFsFkZTg4lCR4y8KBhgoWpaanVqRl5pQgpJk4OEGG8wANPxcGVMNbXJCYW5yZDpE/ xajL8e/m/l5mIZa8/LxUKXFec5BBAiBFGaV5cHNA6Ugie3/NK0ZxoLeEeXtAqniAqQxu0iug JUxAS8oeG4AsKUlESEk1MLL7bCl1zdyrwtCrvf9klVH0vlNH6iwYVup7eDG+1BLJePfPPyD5 1b3P7PdnmJQpNZx82O30/3japVCRpUeeValu3u9/eNc0gecLTu5lsWf8/mra/Exp/WjBqQzy U/p+CP7nZFAymxp4w/j2m5STBl9EhO6/Vz7+unJxZi+bVYZhEF/vLv+jV5VYijMSDbWYi4oT ARsWJhoiAwAA Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 15:14:26 -0000 I thought we were worried about collision of key *identifiers*, which were not necessarily raw keys or hashes thereof. But it's possible I was not paying enough attention and got confused. -Ben On Tue, Jun 26, 2018 at 03:12:52PM +0000, Hannes Tschofenig wrote: > It does answer my question, Ben. > > This begs the question why the collision of session keys is suddenly a problem in the ACE context when it wasn't a problem so far. Something must have changed. > > Ciao > Hannes > > > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: 26 June 2018 17:00 > To: Hannes Tschofenig > Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > On Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote: > > Ben, > > > > I was wondering whether the situation is any different in Kerberos. If the KDC creates tickets with a session key included then it needs to make sure that it does not create the same symmetric key for different usages. > > The key in the Kerberos ticket is similar to the PoP key in our discussion. > > > > Are we aware of key collision in Kerberos? > > I don't believe key collision is an issue in Kerberos. Long-term keys > (which are not what we're talking about here) are identified by a principal > name, encryption type, and version number. Session keys that are contained > within tickets (and returned to the client in the KDC-REP) are random, so > even if we are only using the birthday bound we're still in pretty good > shape. The modern enctypes tend to use subsession keys generated by the > client and/or server as well as the KDC-generated session key, which > provides further binding to the current session. > > Does that answer your question? > > -Ben > 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. From nobody Tue Jun 26 09:08:53 2018 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 80DB4130EC7; Tue, 26 Jun 2018 09:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 Tji55zsd6mzu; Tue, 26 Jun 2018 09:08:48 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320DE130ED1; Tue, 26 Jun 2018 09:08:47 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=bdHiMj07om9gXizrjge1TxXMfL58OhWUX7hlWBGXXUM=; b=G4pfEoZKd3pAD31/V5Y4YXQqOk3f+t81dqZ8HObUIbesUxcs1hmKmUsgqmmKgLNmhEx/Dcpb133P8qO+wIAdPsOfp3fJkG1gDguuM3Dar5KHJ6LDiwPzLiS25sHRxYSkGMZhWzMJm2gYmbZ/sTm9M88KQ5OPcFw1AChrvsu+2pc= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1920.eurprd08.prod.outlook.com (10.173.73.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.20; Tue, 26 Jun 2018 16:08:44 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%9]) with mapi id 15.20.0884.024; Tue, 26 Jun 2018 16:08:44 +0000 From: Hannes Tschofenig To: Benjamin Kaduk CC: Mike Jones , Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AQHUCmm7VfkGifo3LEWkTqcB1vlZy6Rsv/OAgAGd44CAA+LVoIAAZzsAgAADOlCAAAC+AIAABF6A Date: Tue, 26 Jun 2018 16:08:42 +0000 Message-ID: References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <20180626150003.GD79565@kduck.kaduk.org> <20180626151415.GE79565@kduck.kaduk.org> In-Reply-To: <20180626151415.GE79565@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.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1920; 7:MUH73LihXAyNPAXx2J2bI5R7iYMsUzPdoLinivuzCVuuNPgQ7qr28apvvpG7edn4xXM9PlDZh2MsQafmLefYRxll7SRBB09AKPh1O4NceBjlZYkvJiBeJQ4chMOlAC1RJ34FGmXZkIpuVaFnB7Bjgu96oSn9WFwuzJ/84SFo6+yvasLQEZYctghq2xfDZfKAZ0v6UjiFOJH/zSDqSiihdzwKdFscCNT3o/+QaJ/YHKra4NAaCo3n58YAWPAMjzlE x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ccabf03b-f295-4f76-caa8-08d5db7f17a6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1920; x-ms-traffictypediagnostic: VI1PR0801MB1920: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(223705240517415)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1920; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1920; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(376002)(366004)(346002)(199004)(189003)(13464003)(40434004)(105586002)(97736004)(81166006)(81156014)(229853002)(99286004)(6436002)(2900100001)(66066001)(14454004)(54906003)(93886005)(72206003)(106356001)(68736007)(316002)(86362001)(14444005)(256004)(478600001)(8676002)(4326008)(7696005)(8936002)(74316002)(305945005)(5024004)(7736002)(5660300001)(26005)(33656002)(53936002)(25786009)(6916009)(6116002)(186003)(5250100002)(11346002)(76176011)(486006)(446003)(102836004)(476003)(53546011)(6506007)(6246003)(2171002)(2906002)(3846002)(9686003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1920; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: vuNDplRC+boDI37JUXDfZJdTs+qtqiumk7enFk35PD/SLlAPvxlezKnjY+7V8LtbOxaZ5umZeY4I+0vVRBhvkFshu+TwQ/qyfR+L6bEOVc/yM96O3jx/RpTAo38WrXQAhR9L/mWdKXlc60UdXMCAnDb/4XBCb+VWxNhaNBPVrRIf7H5cg9OIsuWU+WQfgmyRu7os35+TIvjEPvo9LwliByV+eTg5a3eqQaOyIHAFAMRU48qaLBwWBSUCysKftPCSMRb/pl5q6Y0m3GxYHUBbvo3NTOFj0wsATsR3u9Om5BpqQOmrJByoELmXp2SpLemkBQqtoqlq2UDGhMgBxjjQ3E/DeGHRcHs4lHvm+Qaq9rs= 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: ccabf03b-f295-4f76-caa8-08d5db7f17a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 16:08:42.9741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1920 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 16:08:52 -0000 Hi Ben, You are right. We were talking about the key identifiers. Let me still stick with the Kerberos example. In that context this would me= an that the KDC stores multiple accounts in the database that point to the = same principal name. Have you seen that happening? Re-using the same principle name over time as identifier get recycle when u= sers get retired or otherwise leave the system might be an option. Is this = a more likely? As you see I am trying to find some examples of vulnerabilities in existing= systems and I am having a hard time. Ciao Hannes -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@mit.edu] Sent: 26 June 2018 17:14 To: Hannes Tschofenig Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.org= ; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-poss= ession-02 I thought we were worried about collision of key *identifiers*, which were not necessarily raw keys or hashes thereof. But it's possible I was not paying enough attention and got confused. -Ben On Tue, Jun 26, 2018 at 03:12:52PM +0000, Hannes Tschofenig wrote: > It does answer my question, Ben. > > This begs the question why the collision of session keys is suddenly a pr= oblem in the ACE context when it wasn't a problem so far. Something must ha= ve changed. > > Ciao > Hannes > > > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: 26 June 2018 17:00 > To: Hannes Tschofenig > Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.o= rg; ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-po= ssession-02 > > On Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote: > > Ben, > > > > I was wondering whether the situation is any different in Kerberos. If = the KDC creates tickets with a session key included then it needs to make s= ure that it does not create the same symmetric key for different usages. > > The key in the Kerberos ticket is similar to the PoP key in our discuss= ion. > > > > Are we aware of key collision in Kerberos? > > I don't believe key collision is an issue in Kerberos. Long-term keys > (which are not what we're talking about here) are identified by a princip= al > name, encryption type, and version number. Session keys that are contain= ed > within tickets (and returned to the client in the KDC-REP) are random, so > even if we are only using the birthday bound we're still in pretty good > shape. The modern enctypes tend to use subsession keys generated by the > client and/or server as well as the KDC-generated session key, which > provides further binding to the current session. > > Does that answer your question? > > -Ben > IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n 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 Tue Jun 26 09:09:01 2018 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 3F225131059; Tue, 26 Jun 2018 09:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 i2ZUbTqLRuPm; Tue, 26 Jun 2018 09:08:50 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC75131053; Tue, 26 Jun 2018 09:08:48 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=5ND6n+ci5YbkqNYfCwZizt1vqdZxh6DvLX8fYBsTEck=; b=OjmBWoOrLanvNdXcT9whVDjcYa9PjvVeuql0OWk0aAGFiLvlMNhoJZCi8qfMln8L8fo2uP6lawYigjWH3D99yrwimXOYuYYZckl59IR2yr09taLLWw3GHlj+e0wUujpe7q98DRYImjUg8JdJC1YqPvXZPaCq02c5Mkx/VpXQASg= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1920.eurprd08.prod.outlook.com (10.173.73.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.20; Tue, 26 Jun 2018 16:08:45 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%9]) with mapi id 15.20.0884.024; Tue, 26 Jun 2018 16:08:45 +0000 From: Hannes Tschofenig To: Jim Schaad , 'Benjamin Kaduk' , 'Mike Jones' CC: "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AQHUCmm7VfkGifo3LEWkTqcB1vlZy6Rsv/OAgAGd44CAALQmgIADnybQ Date: Tue, 26 Jun 2018 16:08:43 +0000 Message-ID: References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> In-Reply-To: <027401d40b93$6b73b470$425b1d50$@augustcellars.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: [80.92.118.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1920; 7:E75Go6Mqb8R7TXJKbuF+70dH3cBR56duqytR6vGi97ohCw9G4L+QtE2q7Q++Wzc20bw+FP8K473PJ1GdTYZGHHj0VHDfZ0JeENU1H7MArfsJPI+B4v9fr3BBNlEg5/oXo40Xdk4HM1qOX5skr/BT7sFxxHm2aELZEH3yf3PTiZPCQQQXDnUPwgyS7YAWiCsZwNi6oNyGe1JzBOmeEA77Mk9uMEOxNlOvQDJAvxspz2z912wk7sSywtMl9FeG19dA x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4573c565-4ac0-4ead-1662-08d5db7f17f3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1920; x-ms-traffictypediagnostic: VI1PR0801MB1920: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(180628864354917)(89211679590171)(223705240517415)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1920; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1920; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(376002)(366004)(346002)(199004)(189003)(13464003)(40434004)(105586002)(97736004)(81166006)(81156014)(229853002)(99286004)(6436002)(2900100001)(66066001)(14454004)(54906003)(1511001)(93886005)(72206003)(106356001)(68736007)(316002)(86362001)(14444005)(256004)(110136005)(478600001)(8676002)(4326008)(7696005)(8936002)(74316002)(305945005)(5024004)(7736002)(5660300001)(26005)(33656002)(53936002)(25786009)(6116002)(186003)(5250100002)(11346002)(76176011)(486006)(446003)(102836004)(476003)(53546011)(6506007)(6246003)(2171002)(2906002)(3846002)(9686003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1920; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: F4LqiMrhdD92j0Le834dTOiwAWdZepbqvx2RPuDPSZxHKuU1ivYrlcNgUau410c2XzVG5eva8iqlIf2UtZcUWblbEB82mBX2HGXBeA/kfxXMXMeKH+j8JyDdcITXt3iYqS7EHzFiHnt64XqwTWRIg2CBJcSoY6OznOMkq5tlrL8zYUAjyPU13AJdSzvEuJeKnQXlEY7fW4snADJjTF9FCHBkbUhlEnTUthGurxEFOAz+yhwe9J0gKVIlC/tNKI6gh/9C0fv52bWda+pAcxWfAdaDOIvwYgFOVaoK3f+FX2/fOYQPEgw4NdVIUmZwr2fwiPZ/C6lhefG+bZVzN+Q7Sd2zory2lJjJa+F9WkIczd4= 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: 4573c565-4ac0-4ead-1662-08d5db7f17f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 16:08:43.6304 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1920 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 16:08:53 -0000 Hi Jim, you are essentially proposing that we should not directly use the key id th= at is in the CWT-PoP but rather use it as input in a key derivation functio= n. The details of that key derivation function are specified outside the CW= T-POP document and most likely in the context of the various profiles. Your proposals below suggest to use, among other things, the session key as= input to that function. That sounds pretty straight forward but raises the= question why we fail to trust the implementer to create random key ids but= then still trust them to create random keys. That's fine for me nevertheless. Ciao Hannes -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: 24 June 2018 10:15 To: 'Benjamin Kaduk'; 'Mike Jones' Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace= @ietf.org Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-poss= ession-02 Thinking things through, I would be more comfortable with something like th= e following: 1. Create a confirmation called 'computed key id'. This has two basic values: What is the computation method? What is the proof value? You can optionally have an unprotected KID value used to filter the set of keys on the RS down to a reasonable set to enumerate (hopefully one). 2. For RPK and TLS: Define a method called hash of SPKI which has a hash method as a parameter. Given that this can be computed independently by al= l entities based on a Public Key value and it will be unique then you have a key identifier that will not have collisions independent of who issues the CWT. 3. For PSK and TLS: Define a method which takes some parameters including the key value, the CWT issuer identity and perhaps some random string and compute a proof of possession value on the PSK. 4. For PSK and OSCORE: Define a similar method the question would be what the key value is to be used but that can be defined as part of OSCORE When using the keys for TLS For RPK the key is carried in the handshake and the server/client can generate the computed key id and compare it to what the AS distributed. Th= e server can identify which CWTs are applicable by either comparison of the RPKs or the computed key id. This means you have a high probability that you will not make a mistake and match to the wrong key. For PSK the identifier is carried in the handshake which is used to look up a key value and the handshake is performed. By matching computed key ids with the secret value one can ensure to a high probably that only CWTs that reference the same secret are going to be used for permissions even if they come from different AS entities. For OSCORE it is similar, the identifier is used to look up a key value and by decrypting the CWT the key value is proofed. You then match computed ke= y ids in the same manner. If you really want to have something that is not cryptographically computed and point to something else, then it makes more sense to me to reference a CWT issued by the same entity and say "use the same conformation method as this CWT does". jim > -----Original Message----- > From: Benjamin Kaduk > Sent: Saturday, June 23, 2018 11:30 PM > To: Mike Jones > Cc: Hannes Tschofenig ; Jim Schaad > ; draft-ietf-ace-cwt-proof-of-possession@ietf.org= ; > ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > See my note just now proposing this text to Jim: > > > > "Likewise, if PoP keys are used for multiple different kinds of CWTs in an > application and the PoP keys are identified by Key IDs, care must be take= n to > keep the keys for the different kinds of CWTs segregated so that an attacker > cannot cause the wrong PoP key to be used by using a valid Key ID for the > wrong kind of CWT." > > > > As long as the PoP keys for different contexts are kept segregated, Key ID > collisions or reuse cause no problems. > > If we trust everyone to implement things properly. We should probably only > take that risk if we get some other benefit from it, though. Jim mentioned > (off-list?) a scenario involving giving the same client additional privileges, and > of course we can gain some simplicity savings if we don't need to enforce > global key-id uniqueness (for appropriate values of "global"). So this may > well be the right thing to do; I just don't think it's without tradeoffs as your > text seems to imply. > > -Ben 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 Jun 26 09:46:18 2018 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 23B141310B9; Tue, 26 Jun 2018 09:46:17 -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 ihSBUxRz3U1I; Tue, 26 Jun 2018 09:46:14 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 A6C10130EBF; Tue, 26 Jun 2018 09:46:14 -0700 (PDT) X-AuditID: 12074424-37dff700000073cb-e6-5b326dd5f51f 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 23.13.29643.5DD623B5; Tue, 26 Jun 2018 12:46:13 -0400 (EDT) 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 w5QGkB78017048; Tue, 26 Jun 2018 12:46:12 -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 w5QGk7Xu016641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jun 2018 12:46:09 -0400 Date: Tue, 26 Jun 2018 11:46:06 -0500 From: Benjamin Kaduk To: Hannes Tschofenig Cc: Mike Jones , Jim Schaad , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Message-ID: <20180626164603.GJ79565@kduck.kaduk.org> References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <20180626150003.GD79565@kduck.kaduk.org> <20180626151415.GE79565@kduck.kaduk.org> 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+NgFprIKsWRmVeSWpSXmKPExsUixCmqrHs11yjaYM0WaYvv33qYLX7+u85s cXPGKSaL1dO/s1nsnfaJxYHVY828NYweG+dMZ/NYsuQnk0frjr/sASxRXDYpqTmZZalF+nYJ XBmvt7YyF0zWrHg87yZ7A+NSxS5GTg4JAROJ122/WboYuTiEBBYzSRxv/ckG4WxklLixcisj hHOVSWLCmf2sIC0sAqoSZ5adZwOx2QRUJBq6LzOD2CIChhJ7mw+xgjQwC3xglLiw4SYLSEJY IEziyYO1jCA2L9C+jTunMEFMfcIisebjCiaIhKDEyZlPwBqYBbQkbvx7CRTnALKlJZb/4wAx OQUSJVbMDQOpEBVQltjbd4h9AqPALCTNs5A0z0JoXsDIvIpRNiW3Sjc3MTOnODVZtzg5MS8v tUjXXC83s0QvNaV0EyMotNldVHYwdvd4H2IU4GBU4uG9YW8ULcSaWFZcmXuIUZKDSUmU94Mz UIgvKT+lMiOxOCO+qDQntfgQowQHs5II77G3htFCvCmJlVWpRfkwKWkOFiVx3txFjNFCAumJ JanZqakFqUUwWRkODiUJXnVgDAsJFqWmp1akZeaUIKSZODhBhvMADdfNAarhLS5IzC3OTIfI n2LU5fh3c38vsxBLXn5eqpQ47xmQIgGQoozSPLg5oJQkkb2/5hWjONBbwrxRIFU8wHQGN+kV 0BImoCVljw1AlpQkIqSkGhjnzPmks2TrwqDKn/0Ku3zepj1uZty91Oxa0PGVlheOzJDZ/fjY qm42H7+Tf6b2+LNdzeltSRGIS23VDPgoqu9sICDCd/vazqI/Rw9PT9GfNztnhsack8cWLF34 0aRxYt2nF9Fr716Otu/6aOe1XbNQYmusyKxLnUIL98etWfzwz6Y5V4wNGd/EKrEUZyQaajEX FScCAFyeSYQkAwAA Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 16:46:18 -0000 In Kerberos, the full principal name includes a realm name as well as the name of the principal itself; this realm would be roughly analogous to an OAuth Issuer. There are plenty of case where there are collisions between the non-realm portion of the Kerberos principal; for example, I control all of kaduk@ATHENA.MIT.EDU, kaduk@ZONE.MIT.EDU, and kaduk@GRAND.CENTRAL.ORG but apply different levels of trust and privilege to them. A more poignant example would be the case of bjk@FREEBSD.ORG and bjk@ATHENA.MIT.EDU, of which I control the former but not the latter. There is some potential for actual issues when the GSSAPI is involved, since the standard way to pick a server ("GSS acceptor") to talk to is to generate a host-based principal name, e.g., service="host" and hostname="ssh.dialup.example.com", which does not include Kerberos realm information (since the GSSAPI does not have such a concept). The Kerberos library uses the hostname and some mapping rules/heuristics to pick a Kerberos realm to use for ssh.dialup.example.com, but if the heuristic is wrong for a particular case, an attacker could acquire that service principal in the "wrong" realm, MITM, and appear to make the client connect successfully. (Non-MITM'd connections would fail, though, so this is likely to be detected quickly as a configuration error.) Within a single realm (and database), there is equivalence between account and principal name, though there are some occurrences of re-use of the same principal name when users or machines leave the system and reenter. There is usually a broad time separtation for that, though. -Ben On Tue, Jun 26, 2018 at 04:08:42PM +0000, Hannes Tschofenig wrote: > Hi Ben, > > You are right. We were talking about the key identifiers. > > Let me still stick with the Kerberos example. In that context this would mean that the KDC stores multiple accounts in the database that point to the same principal name. Have you seen that happening? > Re-using the same principle name over time as identifier get recycle when users get retired or otherwise leave the system might be an option. Is this a more likely? > > As you see I am trying to find some examples of vulnerabilities in existing systems and I am having a hard time. > > Ciao > Hannes > > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: 26 June 2018 17:14 > To: Hannes Tschofenig > Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > I thought we were worried about collision of key *identifiers*, which were > not necessarily raw keys or hashes thereof. But it's possible I was not > paying enough attention and got confused. > > -Ben > > On Tue, Jun 26, 2018 at 03:12:52PM +0000, Hannes Tschofenig wrote: > > It does answer my question, Ben. > > > > This begs the question why the collision of session keys is suddenly a problem in the ACE context when it wasn't a problem so far. Something must have changed. > > > > Ciao > > Hannes > > > > > > -----Original Message----- > > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Sent: 26 June 2018 17:00 > > To: Hannes Tschofenig > > Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > > > On Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote: > > > Ben, > > > > > > I was wondering whether the situation is any different in Kerberos. If the KDC creates tickets with a session key included then it needs to make sure that it does not create the same symmetric key for different usages. > > > The key in the Kerberos ticket is similar to the PoP key in our discussion. > > > > > > Are we aware of key collision in Kerberos? > > > > I don't believe key collision is an issue in Kerberos. Long-term keys > > (which are not what we're talking about here) are identified by a principal > > name, encryption type, and version number. Session keys that are contained > > within tickets (and returned to the client in the KDC-REP) are random, so > > even if we are only using the birthday bound we're still in pretty good > > shape. The modern enctypes tend to use subsession keys generated by the > > client and/or server as well as the KDC-generated session key, which > > provides further binding to the current session. > > > > Does that answer your question? > > > > -Ben > > 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. > 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. From nobody Tue Jun 26 09:54:39 2018 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 4672E130E07; Tue, 26 Jun 2018 09:54:38 -0700 (PDT) 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 WusbvF9u8pLZ; Tue, 26 Jun 2018 09:54:36 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EDD130EBF; Tue, 26 Jun 2018 09:54:36 -0700 (PDT) Received: from Jude (151.127.12.101) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 26 Jun 2018 09:51:26 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'Hannes Tschofenig' CC: 'Mike Jones' , , References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <20180626150003.GD79565@kduck.kaduk.org> <20180626151415.GE79565@kduck.kaduk.org> In-Reply-To: <20180626151415.GE79565@kduck.kaduk.org> Date: Tue, 26 Jun 2018 18:54:23 +0200 Message-ID: <00e601d40d6e$593eab70$0bbc0250$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQHH3wOzAp0N2z4AwuijgAGW3xIRAhu0accCDpuegAI+hUiQouR84aA= X-Originating-IP: [151.127.12.101] Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 16:54:39 -0000 No Ben, you are 100% correct. This is about identifiers and not session keys. > -----Original Message----- > From: Benjamin Kaduk > Sent: Tuesday, June 26, 2018 5:14 PM > To: Hannes Tschofenig > Cc: Mike Jones ; Jim Schaad > ; draft-ietf-ace-cwt-proof-of-possession@ietf.org; > ace@ietf.org > Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > I thought we were worried about collision of key *identifiers*, which were > not necessarily raw keys or hashes thereof. But it's possible I was not paying > enough attention and got confused. > > -Ben > > On Tue, Jun 26, 2018 at 03:12:52PM +0000, Hannes Tschofenig wrote: > > It does answer my question, Ben. > > > > This begs the question why the collision of session keys is suddenly a > problem in the ACE context when it wasn't a problem so far. Something must > have changed. > > > > Ciao > > Hannes > > > > > > -----Original Message----- > > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Sent: 26 June 2018 17:00 > > To: Hannes Tschofenig > > Cc: Mike Jones; Jim Schaad; > > draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > draft-ietf-ace-cwt-proof-of-possession-02 > > > > On Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote: > > > Ben, > > > > > > I was wondering whether the situation is any different in Kerberos. If the > KDC creates tickets with a session key included then it needs to make sure > that it does not create the same symmetric key for different usages. > > > The key in the Kerberos ticket is similar to the PoP key in our discussion. > > > > > > Are we aware of key collision in Kerberos? > > > > I don't believe key collision is an issue in Kerberos. Long-term keys > > (which are not what we're talking about here) are identified by a > > principal name, encryption type, and version number. Session keys > > that are contained within tickets (and returned to the client in the > > KDC-REP) are random, so even if we are only using the birthday bound > > we're still in pretty good shape. The modern enctypes tend to use > > subsession keys generated by the client and/or server as well as the > > KDC-generated session key, which provides further binding to the current > session. > > > > Does that answer your question? > > > > -Ben > > 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. From nobody Tue Jun 26 09:57:35 2018 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 C54AD130EF9; Tue, 26 Jun 2018 09:57:32 -0700 (PDT) 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 a1_tMoatwpBl; Tue, 26 Jun 2018 09:57:30 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB851310C1; Tue, 26 Jun 2018 09:57:29 -0700 (PDT) Received: from Jude (151.127.12.101) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 26 Jun 2018 09:54:20 -0700 From: Jim Schaad To: 'Hannes Tschofenig' , 'Benjamin Kaduk' , 'Mike Jones' CC: , References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> In-Reply-To: Date: Tue, 26 Jun 2018 18:57:19 +0200 Message-ID: <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQHH3wOzAp0N2z4AwuijgAIaIIxmAaqrEKejBlSkkA== X-Originating-IP: [151.127.12.101] Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 26 Jun 2018 16:57:34 -0000 Hannes, My worry is not about implementers getting this correct and picking random key ids. My worry is about an attacker seeing the key id of somebody and trying to use it either with the same or a different AS and getting a key and then getting permissions associated with the initial key that they should not be doing. This is about an attack not about getting things to generally work right. Jim > -----Original Message----- > From: Hannes Tschofenig > Sent: Tuesday, June 26, 2018 6:09 PM > To: Jim Schaad ; 'Benjamin Kaduk' > ; 'Mike Jones' > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > Hi Jim, > > you are essentially proposing that we should not directly use the key id that > is in the CWT-PoP but rather use it as input in a key derivation function. The > details of that key derivation function are specified outside the CWT-POP > document and most likely in the context of the various profiles. > Your proposals below suggest to use, among other things, the session key as > input to that function. That sounds pretty straight forward but raises the > question why we fail to trust the implementer to create random key ids but > then still trust them to create random keys. > > That's fine for me nevertheless. > > Ciao > Hannes > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: 24 June 2018 10:15 > To: 'Benjamin Kaduk'; 'Mike Jones' > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org; > ace@ietf.org > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > Thinking things through, I would be more comfortable with something like > the > following: > > 1. Create a confirmation called 'computed key id'. This has two basic > values: What is the computation method? What is the proof value? You can > optionally have an unprotected KID value used to filter the set of keys on the > RS down to a reasonable set to enumerate (hopefully one). > > 2. For RPK and TLS: Define a method called hash of SPKI which has a hash > method as a parameter. Given that this can be computed independently by > all entities based on a Public Key value and it will be unique then you have a > key identifier that will not have collisions independent of who issues the > CWT. > > 3. For PSK and TLS: Define a method which takes some parameters including > the key value, the CWT issuer identity and perhaps some random string and > compute a proof of possession value on the PSK. > > 4. For PSK and OSCORE: Define a similar method the question would be what > the key value is to be used but that can be defined as part of OSCORE > > When using the keys for TLS > > For RPK the key is carried in the handshake and the server/client can > generate the computed key id and compare it to what the AS distributed. > The server can identify which CWTs are applicable by either comparison of > the RPKs or the computed key id. This means you have a high probability > that you will not make a mistake and match to the wrong key. > > For PSK the identifier is carried in the handshake which is used to look up a > key value and the handshake is performed. By matching computed key ids > with the secret value one can ensure to a high probably that only CWTs that > reference the same secret are going to be used for permissions even if they > come from different AS entities. > > For OSCORE it is similar, the identifier is used to look up a key value and by > decrypting the CWT the key value is proofed. You then match computed key > ids in the same manner. > > If you really want to have something that is not cryptographically computed > and point to something else, then it makes more sense to me to reference a > CWT issued by the same entity and say "use the same conformation method > as this CWT does". > > jim > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Saturday, June 23, 2018 11:30 PM > > To: Mike Jones > > Cc: Hannes Tschofenig ; Jim Schaad > > ; > > draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > ace@ietf.org > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > See my note just now proposing this text to Jim: > > > > > > "Likewise, if PoP keys are used for multiple different kinds of CWTs > > > in > an > > application and the PoP keys are identified by Key IDs, care must be > > taken > to > > keep the keys for the different kinds of CWTs segregated so that an > attacker > > cannot cause the wrong PoP key to be used by using a valid Key ID for > > the wrong kind of CWT." > > > > > > As long as the PoP keys for different contexts are kept segregated, > > > Key > ID > > collisions or reuse cause no problems. > > > > If we trust everyone to implement things properly. We should probably > only > > take that risk if we get some other benefit from it, though. Jim > mentioned > > (off-list?) a scenario involving giving the same client additional > privileges, and > > of course we can gain some simplicity savings if we don't need to > > enforce global key-id uniqueness (for appropriate values of "global"). > > So this > may > > well be the right thing to do; I just don't think it's without > > tradeoffs > as your > > text seems to imply. > > > > -Ben > > 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. From nobody Tue Jun 26 23:18:08 2018 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 17550130F3F for ; Tue, 26 Jun 2018 23:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=spotify.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 UT_XzedsuC3h for ; Tue, 26 Jun 2018 23:18:01 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 9C018130E80 for ; Tue, 26 Jun 2018 23:18:01 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id p17-v6so805378itc.2 for ; Tue, 26 Jun 2018 23:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spotify.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SDFcIOrQPoppm+GEgNRMyt0xBKtfBeWBMDFLvgnMpds=; b=B1MuBobYxAY7QHzF4474I3bHRtVkXnLbrPu+K/GSe+aEz3C1Jt6fS+F+mIsRj/oiQD I3f5ROfK3zwCWd+UkW9vOZMOAsAif36YderPNdFvqXlK0urcurT65qBAaQhW1HzsXpvW 2Dz1+XzCK7Kifz1bXLJ5JEenGJrvnHUMnQ45A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SDFcIOrQPoppm+GEgNRMyt0xBKtfBeWBMDFLvgnMpds=; b=U2yZK9aZ/Lhe/40hzQRkfP3rjcpQFRIMx3A8uv0pm8rHgavObPwSXTMr2CaX21eV4/ shuB3gHXaxgUFbwZYbxDScR1aQdKKJMIpLjts7+v1VD9za+EJlhyWpm/sJQeAlBfZjje zCaefLu7PM31li0QzAUQtIx/xGKvswpV1nymktnD2ysqXeUVG2V4+h2AQhDez0VE9Qy5 xVA3SrHUp1hO1ZZzhvnbRvt2zzsMXEFCRgy2CLi4RVcDVIIl2/I4MphgYWp8jfEXAB0x MuULRovWC+FNJf8j7Aen44yyVmXOnyWQTG8arpXsHuzN4tzk3zB0wTWKHd6uqsEPlWWp 36Hw== X-Gm-Message-State: APt69E1Ph5wrX+R/FI28L1qdoP6gIgQGp++b1BJf1GxAgRG+P27s/S5X vkTtzCxmX3p3/AiiyR1FMgF5BWNlN/5HkEHKWURisg== X-Google-Smtp-Source: AAOMgpfjojMN65W0JjzSduxXAwLqMLl9DtQr6OFPO75uOXL1mRCvZzZFiGk7W6Hk0C4uEOzzBOy+WyQZ6js5xdvpjak= X-Received: by 2002:a24:a13:: with SMTP id 19-v6mr197655itw.41.1530080280777; Tue, 26 Jun 2018 23:18:00 -0700 (PDT) MIME-Version: 1.0 References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> In-Reply-To: <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> From: Samuel Erdtman Date: Wed, 27 Jun 2018 08:17:48 +0200 Message-ID: To: Jim Schaad Cc: Hannes Tschofenig , Benjamin Kaduk , Mike Jones , draft-ietf-ace-cwt-proof-of-possession@ietf.org, ace@ietf.org Content-Type: multipart/alternative; boundary="0000000000009d345b056f99938b" Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 27 Jun 2018 06:18:06 -0000 --0000000000009d345b056f99938b Content-Type: text/plain; charset="UTF-8" Jim, are you saying that if the client can pick the key identifier and if it has seen a key identifier of another client it could request a PoP token with the observed key-id and the observed subject but with an new key. I guess this is a potential scenario that could be worth mentioning in security considerations. If we look at ACE-OAuth there are as far as I can tell a few things that makes this a hard attack to do. When the client makes the token request it is authenticated. And with the subject being the authenticated client cannot control what goes into the cwt as subject Since the cwt with the PoP key is signed there is no way for the attacking client to retro-fit the token to suit its needs e.g. change subject or key-id. Finally I think it is preferable if the server selects key identifier. Best regards //Samuel On Tue, 26 Jun 2018 at 18:57, Jim Schaad wrote: > Hannes, > > My worry is not about implementers getting this correct and picking random > key ids. My worry is about an attacker seeing the key id of somebody and > trying to use it either with the same or a different AS and getting a key > and then getting permissions associated with the initial key that they > should not be doing. > > This is about an attack not about getting things to generally work right. > > Jim > > > > -----Original Message----- > > From: Hannes Tschofenig > > Sent: Tuesday, June 26, 2018 6:09 PM > > To: Jim Schaad ; 'Benjamin Kaduk' > > ; 'Mike Jones' > > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Hi Jim, > > > > you are essentially proposing that we should not directly use the key id > that > > is in the CWT-PoP but rather use it as input in a key derivation > function. > The > > details of that key derivation function are specified outside the CWT-POP > > document and most likely in the context of the various profiles. > > Your proposals below suggest to use, among other things, the session key > as > > input to that function. That sounds pretty straight forward but raises > the > > question why we fail to trust the implementer to create random key ids > but > > then still trust them to create random keys. > > > > That's fine for me nevertheless. > > > > Ciao > > Hannes > > > > -----Original Message----- > > From: Jim Schaad [mailto:ietf@augustcellars.com] > > Sent: 24 June 2018 10:15 > > To: 'Benjamin Kaduk'; 'Mike Jones' > > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > ace@ietf.org > > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Thinking things through, I would be more comfortable with something like > > the > > following: > > > > 1. Create a confirmation called 'computed key id'. This has two basic > > values: What is the computation method? What is the proof value? You > can > > optionally have an unprotected KID value used to filter the set of keys > on > the > > RS down to a reasonable set to enumerate (hopefully one). > > > > 2. For RPK and TLS: Define a method called hash of SPKI which has a > hash > > method as a parameter. Given that this can be computed independently by > > all entities based on a Public Key value and it will be unique then you > have a > > key identifier that will not have collisions independent of who issues > the > > CWT. > > > > 3. For PSK and TLS: Define a method which takes some parameters > including > > the key value, the CWT issuer identity and perhaps some random string and > > compute a proof of possession value on the PSK. > > > > 4. For PSK and OSCORE: Define a similar method the question would be > what > > the key value is to be used but that can be defined as part of OSCORE > > > > When using the keys for TLS > > > > For RPK the key is carried in the handshake and the server/client can > > generate the computed key id and compare it to what the AS distributed. > > The server can identify which CWTs are applicable by either comparison of > > the RPKs or the computed key id. This means you have a high probability > > that you will not make a mistake and match to the wrong key. > > > > For PSK the identifier is carried in the handshake which is used to look > up a > > key value and the handshake is performed. By matching computed key ids > > with the secret value one can ensure to a high probably that only CWTs > that > > reference the same secret are going to be used for permissions even if > they > > come from different AS entities. > > > > For OSCORE it is similar, the identifier is used to look up a key value > and by > > decrypting the CWT the key value is proofed. You then match computed key > > ids in the same manner. > > > > If you really want to have something that is not cryptographically > computed > > and point to something else, then it makes more sense to me to reference > a > > CWT issued by the same entity and say "use the same conformation method > > as this CWT does". > > > > jim > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Saturday, June 23, 2018 11:30 PM > > > To: Mike Jones > > > Cc: Hannes Tschofenig ; Jim Schaad > > > ; > > > draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > > ace@ietf.org > > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > > draft-ietf-ace-cwt-proof-of- > > > possession-02 > > > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > > See my note just now proposing this text to Jim: > > > > > > > > "Likewise, if PoP keys are used for multiple different kinds of CWTs > > > > in > > an > > > application and the PoP keys are identified by Key IDs, care must be > > > taken > > to > > > keep the keys for the different kinds of CWTs segregated so that an > > attacker > > > cannot cause the wrong PoP key to be used by using a valid Key ID for > > > the wrong kind of CWT." > > > > > > > > As long as the PoP keys for different contexts are kept segregated, > > > > Key > > ID > > > collisions or reuse cause no problems. > > > > > > If we trust everyone to implement things properly. We should probably > > only > > > take that risk if we get some other benefit from it, though. Jim > > mentioned > > > (off-list?) a scenario involving giving the same client additional > > privileges, and > > > of course we can gain some simplicity savings if we don't need to > > > enforce global key-id uniqueness (for appropriate values of "global"). > > > So this > > may > > > well be the right thing to do; I just don't think it's without > > > tradeoffs > > as your > > > text seems to imply. > > > > > > -Ben > > > > 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. > > --0000000000009d345b056f99938b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jim, are you saying that if the client can pick the key identifier and if i= t has seen a key identifier of another client it could request a PoP token = with the observed key-id and the observed subject but with an new key.
= I guess this is a potential scenario that could be worth mentioning in secu= rity considerations.

If we look at ACE-OAuth there are as far as I c= an tell a few things that makes this a hard attack to do.

When the c= lient makes the token request it is authenticated.

And with the subj= ect being the authenticated client cannot control what goes into the cwt as= subject

Since the cwt with the PoP key is signed there is no way fo= r the attacking client to retro-fit the token to suit its needs e.g. change= subject or key-id.

Finally I think it is preferable if the server s= elects key identifier.

Best regards
//Samuel



Hannes,

My worry is not about implementers getting this correct and picking random<= br> key ids.=C2=A0 My worry is about an attacker seeing the key id of somebody = and
trying to use it either with the same or a different AS and getting a key and then getting permissions associated with the initial key that they
should not be doing.

This is about an attack not about getting things to generally work right.
Jim


> -----Original Message-----
> From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad <ietf@augustcellars.com>; 'Benjamin Kaduk'
> <kaduk@mit.edu>; 'Mike Jones' <Michael.Jones@microsoft.com>
> Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of= -
> possession-02
>
> Hi Jim,
>
> you are essentially proposing that we should not directly use the key = id
that
> is in the CWT-PoP but rather use it as input in a key derivation funct= ion.
The
> details of that key derivation function are specified outside the CWT-= POP
> document and most likely in the context of the various profiles.
> Your proposals below suggest to use, among other things, the session k= ey
as
> input to that function. That sounds pretty straight forward but raises= the
> question why we fail to trust the implementer to create random key ids= but
> then still trust them to create random keys.
>
> That's fine for me nevertheless.
>
> Ciao
> Hannes
>
> -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possessio= n@ietf.org;
> ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of= -
> possession-02
>
> Thinking things through, I would be more comfortable with something li= ke
> the
> following:
>
> 1.=C2=A0 Create a confirmation called 'computed key id'.=C2=A0= This has two basic
> values:=C2=A0 What is the computation method?=C2=A0 What is the proof = value?=C2=A0 You
can
> optionally have an unprotected KID value used to filter the set of key= s on
the
> RS down to a reasonable set to enumerate (hopefully one).
>
> 2.=C2=A0 For RPK and TLS:=C2=A0 Define a method called hash of SPKI wh= ich has a hash
> method as a parameter.=C2=A0 Given that this can be computed independe= ntly by
> all entities based on a Public Key value and it will be unique then yo= u
have a
> key identifier that will not have collisions independent of who issues= the
> CWT.
>
> 3.=C2=A0 For PSK and TLS:=C2=A0 Define a method which takes some param= eters
including
> the key value, the CWT issuer identity and perhaps some random string = and
> compute a proof of possession value on the PSK.
>
> 4.=C2=A0 For PSK and OSCORE: Define a similar method the question woul= d be what
> the key value is to be used but that can be defined as part of OSCORE<= br> >
> When using the keys for TLS
>
> For RPK the key is carried in the handshake and the server/client can<= br> > generate the computed key id and compare it to what the AS distributed= .
> The server can identify which CWTs are applicable by either comparison= of
> the RPKs or the computed key id.=C2=A0 This means you have a high prob= ability
> that you will not make a mistake and match to the wrong key.
>
> For PSK the identifier is carried in the handshake which is used to lo= ok
up a
> key value and the handshake is performed.=C2=A0 By matching computed k= ey ids
> with the secret value one can ensure to a high probably that only CWTs=
that
> reference the same secret are going to be used for permissions even if=
they
> come from different AS entities.
>
> For OSCORE it is similar, the identifier is used to look up a key valu= e
and by
> decrypting the CWT the key value is proofed.=C2=A0 You then match comp= uted key
> ids in the same manner.
>
> If you really want to have something that is not cryptographically
computed
> and point to something else, then it makes more sense to me to referen= ce a
> CWT issued by the same entity and say "use the same conformation = method
> as this CWT does".
>
> jim
>
> > -----Original Message-----
> > From: Benjamin Kaduk <kaduk@mit.edu>
> > Sent: Saturday, June 23, 2018 11:30 PM
> > To: Mike Jones <Michael.Jones@microsoft.com>
> > Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Jim Schaad
> > <i= etf@augustcellars.com>;
> > draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote:
> > > See my note just now proposing this text to Jim:
> > >
> > > "Likewise, if PoP keys are used for multiple different = kinds of CWTs
> > > in
> an
> > application and the PoP keys are identified by Key IDs, care must= be
> > taken
> to
> > keep the keys for the different kinds of CWTs segregated so that = an
> attacker
> > cannot cause the wrong PoP key to be used by using a valid Key ID= for
> > the wrong kind of CWT."
> > >
> > > As long as the PoP keys for different contexts are kept segr= egated,
> > > Key
> ID
> > collisions or reuse cause no problems.
> >
> > If we trust everyone to implement things properly.=C2=A0 We shoul= d probably
> only
> > take that risk if we get some other benefit from it, though.=C2= =A0 Jim
> mentioned
> > (off-list?) a scenario involving giving the same client additiona= l
> privileges, and
> > of course we can gain some simplicity savings if we don't nee= d to
> > enforce global key-id uniqueness (for appropriate values of "= ;global").
> > So this
> may
> > well be the right thing to do; I just don't think it's wi= thout
> > tradeoffs
> as your
> > text seems to imply.
> >
> > -Ben
>
> 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.

--0000000000009d345b056f99938b-- From nobody Wed Jun 27 00:20:04 2018 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 011B4130E87; Wed, 27 Jun 2018 00:20:02 -0700 (PDT) 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, 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 00_QS-jnXWET; Wed, 27 Jun 2018 00:19:59 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AE6130E47; Wed, 27 Jun 2018 00:19:58 -0700 (PDT) Received: from Jude (128.93.88.230) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 27 Jun 2018 00:16:42 -0700 From: Jim Schaad To: 'Samuel Erdtman' CC: 'Hannes Tschofenig' , 'Benjamin Kaduk' , 'Mike Jones' , , References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> In-Reply-To: Date: Wed, 27 Jun 2018 09:19:41 +0200 Message-ID: <013301d40de7$39660220$ac320660$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01D40DF7.FCF058C0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQHH3wOzAp0N2z4AwuijgAIaIIxmAaqrEKcBY2dBsQHPZ3YMou2tNsA= X-Originating-IP: [128.93.88.230] Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 27 Jun 2018 07:20:02 -0000 ------=_NextPart_000_0134_01D40DF7.FCF058C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Samuel Erdtman =20 Sent: Wednesday, June 27, 2018 8:18 AM To: Jim Schaad Cc: Hannes Tschofenig ; Benjamin Kaduk = ; Mike Jones ; = draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on = draft-ietf-ace-cwt-proof-of-possession-02 =20 Jim, are you saying that if the client can pick the key identifier and = if it has seen a key identifier of another client it could request a PoP = token with the observed key-id and the observed subject but with an new = key.=20 I guess this is a potential scenario that could be worth mentioning in = security considerations. [JLS] No I am not assuming that the observed subject is also chosen by = the attacker, just the observed key-id. If we look at ACE-OAuth there are as far as I can tell a few things that = makes this a hard attack to do. When the client makes the token request it is authenticated. [JLS] Unclear why this is relevant. I am asking for this new token as = myself. And with the subject being the authenticated client cannot control what = goes into the cwt as subject [JLS] You are making an assumption that a) the subject is actually going = to be populated rather than be left empty and thus be anonymous and 2) = that the resource server is going to make any enforcement based on the = subject. I expect it to be done based on audience and scope only. Since the cwt with the PoP key is signed there is no way for the = attacking client to retro-fit the token to suit its needs e.g. change = subject or key-id. [JLS] I am asking for a new token not trying to modify an existing token = so this is not especially relevant. Finally I think it is preferable if the server selects key identifier.=20 [JLS] I would agree, however if you have two AS that are operating in = the same authorization range and are not tightly linked then this is not = easy for doing an additional privilege token where the POP is identified = by the KID. This is even harder if an RS is going to allow two = different AS from different scopes to be authoritative as they would = never coordinate together. Best regards //Samuel On Tue, 26 Jun 2018 at 18:57, Jim Schaad > wrote: Hannes, My worry is not about implementers getting this correct and picking = random key ids. My worry is about an attacker seeing the key id of somebody = and trying to use it either with the same or a different AS and getting a = key and then getting permissions associated with the initial key that they should not be doing. This is about an attack not about getting things to generally work = right. Jim > -----Original Message----- > From: Hannes Tschofenig > > Sent: Tuesday, June 26, 2018 6:09 PM > To: Jim Schaad = >; 'Benjamin Kaduk' > >; 'Mike Jones' = > > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org = ; ace@ietf.org = =20 > Subject: RE: [Ace] Key IDs ... RE: WGLC on = draft-ietf-ace-cwt-proof-of- > possession-02 >=20 > Hi Jim, >=20 > you are essentially proposing that we should not directly use the key = id that > is in the CWT-PoP but rather use it as input in a key derivation = function. The > details of that key derivation function are specified outside the = CWT-POP > document and most likely in the context of the various profiles. > Your proposals below suggest to use, among other things, the session = key as > input to that function. That sounds pretty straight forward but raises = the > question why we fail to trust the implementer to create random key ids = but > then still trust them to create random keys. >=20 > That's fine for me nevertheless. >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com = ] > Sent: 24 June 2018 10:15 > To: 'Benjamin Kaduk'; 'Mike Jones' > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org = ; > ace@ietf.org =20 > Subject: RE: [Ace] Key IDs ... RE: WGLC on = draft-ietf-ace-cwt-proof-of- > possession-02 >=20 > Thinking things through, I would be more comfortable with something = like > the > following: >=20 > 1. Create a confirmation called 'computed key id'. This has two = basic > values: What is the computation method? What is the proof value? = You can > optionally have an unprotected KID value used to filter the set of = keys on the > RS down to a reasonable set to enumerate (hopefully one). >=20 > 2. For RPK and TLS: Define a method called hash of SPKI which has a = hash > method as a parameter. Given that this can be computed independently = by > all entities based on a Public Key value and it will be unique then = you have a > key identifier that will not have collisions independent of who issues = the > CWT. >=20 > 3. For PSK and TLS: Define a method which takes some parameters including > the key value, the CWT issuer identity and perhaps some random string = and > compute a proof of possession value on the PSK. >=20 > 4. For PSK and OSCORE: Define a similar method the question would be = what > the key value is to be used but that can be defined as part of OSCORE >=20 > When using the keys for TLS >=20 > For RPK the key is carried in the handshake and the server/client can > generate the computed key id and compare it to what the AS = distributed. > The server can identify which CWTs are applicable by either comparison = of > the RPKs or the computed key id. This means you have a high = probability > that you will not make a mistake and match to the wrong key. >=20 > For PSK the identifier is carried in the handshake which is used to = look up a > key value and the handshake is performed. By matching computed key = ids > with the secret value one can ensure to a high probably that only CWTs that > reference the same secret are going to be used for permissions even if they > come from different AS entities. >=20 > For OSCORE it is similar, the identifier is used to look up a key = value and by > decrypting the CWT the key value is proofed. You then match computed = key > ids in the same manner. >=20 > If you really want to have something that is not cryptographically computed > and point to something else, then it makes more sense to me to = reference a > CWT issued by the same entity and say "use the same conformation = method > as this CWT does". >=20 > jim >=20 > > -----Original Message----- > > From: Benjamin Kaduk > > > Sent: Saturday, June 23, 2018 11:30 PM > > To: Mike Jones > > > Cc: Hannes Tschofenig >; Jim Schaad > > >; > > draft-ietf-ace-cwt-proof-of-possession@ietf.org = ; > > ace@ietf.org =20 > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > See my note just now proposing this text to Jim: > > > > > > "Likewise, if PoP keys are used for multiple different kinds of = CWTs > > > in > an > > application and the PoP keys are identified by Key IDs, care must be > > taken > to > > keep the keys for the different kinds of CWTs segregated so that an > attacker > > cannot cause the wrong PoP key to be used by using a valid Key ID = for > > the wrong kind of CWT." > > > > > > As long as the PoP keys for different contexts are kept = segregated, > > > Key > ID > > collisions or reuse cause no problems. > > > > If we trust everyone to implement things properly. We should = probably > only > > take that risk if we get some other benefit from it, though. Jim > mentioned > > (off-list?) a scenario involving giving the same client additional > privileges, and > > of course we can gain some simplicity savings if we don't need to > > enforce global key-id uniqueness (for appropriate values of = "global"). > > So this > may > > well be the right thing to do; I just don't think it's without > > tradeoffs > as your > > text seems to imply. > > > > -Ben >=20 > 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. ------=_NextPart_000_0134_01D40DF7.FCF058C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Samuel Erdtman <erdtman@spotify.com>
Sent: Wednesday, = June 27, 2018 8:18 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Hannes Tschofenig = <Hannes.Tschofenig@arm.com>; Benjamin Kaduk <kaduk@mit.edu>; = Mike Jones <Michael.Jones@microsoft.com>; = draft-ietf-ace-cwt-proof-of-possession@ietf.org; = ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on = draft-ietf-ace-cwt-proof-of-possession-02

 

Jim, are you saying that if the client = can pick the key identifier and if it has seen a key identifier of = another client it could request a PoP token with the observed key-id and = the observed subject but with an new key.
I guess this is a = potential scenario that could be worth mentioning in security = considerations.

[JLS] No I am not assuming that the = observed subject is also chosen by the attacker, just the observed = key-id.

If we look at ACE-OAuth there are as far as I can tell a = few things that makes this a hard attack to do.

When the client = makes the token request it is authenticated.

[JLS] Unclear why this = is relevant.=C2=A0 I am asking for this new token as myself.

And = with the subject being the authenticated client cannot control what goes = into the cwt as subject

[JLS] You are making an assumption that = a) the subject is actually going to be populated rather than be left = empty and thus be anonymous and 2) that the resource server is going to = make any enforcement based on the subject.=C2=A0 I expect it to be done = based on audience and scope only.

Since the cwt with the PoP key = is signed there is no way for the attacking client to retro-fit the = token to suit its needs e.g. change subject or key-id.

[JLS] I am asking for a = new token not trying to modify an existing token so this is not = especially relevant.


Finally I think it is preferable if = the server selects key identifier.

[JLS] I would agree, however if you have = two AS that are operating in the same authorization range and are not = tightly linked then this is not easy for doing an additional privilege = token where the POP is identified by the KID.=C2=A0 This is even harder = if an RS is going to allow two different AS from different scopes to be = authoritative as they would never coordinate together.



Best = regards
//Samuel


Hannes,

My worry is not about = implementers getting this correct and picking random
key ids.  = My worry is about an attacker seeing the key id of somebody = and
trying to use it either with the same or a different AS and = getting a key
and then getting permissions associated with the = initial key that they
should not be doing.

This is about an = attack not about getting things to generally work = right.

Jim


> -----Original Message-----
> = From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> Sent: = Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad <ietf@augustcellars.com>; 'Benjamin = Kaduk'
> <kaduk@mit.edu>; 'Mike Jones' <Michael.Jones@microsoft.com>
> Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; = ace@ietf.org
> Subject: RE: [Ace] Key IDs = ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> = possession-02
>
> Hi Jim,
>
> you are = essentially proposing that we should not directly use the key = id
that
> is in the CWT-PoP but rather use it as input in a key = derivation function.
The
> details of that key derivation = function are specified outside the CWT-POP
> document and most = likely in the context of the various profiles.
> Your proposals = below suggest to use, among other things, the session key
as
> = input to that function. That sounds pretty straight forward but raises = the
> question why we fail to trust the implementer to create = random key ids but
> then still trust them to create random = keys.
>
> That's fine for me nevertheless.
>
> = Ciao
> Hannes
>
> -----Original Message-----
> = From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: 24 June 2018 = 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes = Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org;> ace@ietf.org
> Subject: RE: [Ace] Key IDs = ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> = possession-02
>
> Thinking things through, I would be more = comfortable with something like
> the
> following:
> =
> 1.  Create a confirmation called 'computed key id'.  = This has two basic
> values:  What is the computation = method?  What is the proof value?  You
can
> = optionally have an unprotected KID value used to filter the set of keys = on
the
> RS down to a reasonable set to enumerate (hopefully = one).
>
> 2.  For RPK and TLS:  Define a method = called hash of SPKI which has a hash
> method as a = parameter.  Given that this can be computed independently = by
> all entities based on a Public Key value and it will be = unique then you
have a
> key identifier that will not have = collisions independent of who issues the
> CWT.
>
> = 3.  For PSK and TLS:  Define a method which takes some = parameters
including
> the key value, the CWT issuer identity = and perhaps some random string and
> compute a proof of possession = value on the PSK.
>
> 4.  For PSK and OSCORE: Define a = similar method the question would be what
> the key value is to be = used but that can be defined as part of OSCORE
>
> When = using the keys for TLS
>
> For RPK the key is carried in = the handshake and the server/client can
> generate the computed = key id and compare it to what the AS distributed.
> The server can = identify which CWTs are applicable by either comparison of
> the = RPKs or the computed key id.  This means you have a high = probability
> that you will not make a mistake and match to the = wrong key.
>
> For PSK the identifier is carried in the = handshake which is used to look
up a
> key value and the = handshake is performed.  By matching computed key ids
> with = the secret value one can ensure to a high probably that only = CWTs
that
> reference the same secret are going to be used for = permissions even if
they
> come from different AS = entities.
>
> For OSCORE it is similar, the identifier is = used to look up a key value
and by
> decrypting the CWT the key = value is proofed.  You then match computed key
> ids in the = same manner.
>
> If you really want to have something that = is not cryptographically
computed
> and point to something = else, then it makes more sense to me to reference a
> CWT issued = by the same entity and say "use the same conformation = method
> as this CWT does".
>
> jim
> =
> > -----Original Message-----
> > From: Benjamin = Kaduk <kaduk@mit.edu>
> > Sent: Saturday, = June 23, 2018 11:30 PM
> > To: Mike Jones <Michael.Jones@microsoft.com>
> > Cc: = Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Jim Schaad
> = > <ietf@augustcellars.com>;
> > draft-ietf-ace-cwt-proof-of-possession@ietf.org;> > ace@ietf.org
> > Subject: Re: [Ace] Key = IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-
> = > possession-02
> >
> > On Fri, Jun 22, 2018 at = 08:48:35PM +0000, Mike Jones wrote:
> > > See my note just = now proposing this text to Jim:
> > >
> > > = "Likewise, if PoP keys are used for multiple different kinds of = CWTs
> > > in
> an
> > application and the = PoP keys are identified by Key IDs, care must be
> > = taken
> to
> > keep the keys for the different kinds of = CWTs segregated so that an
> attacker
> > cannot cause = the wrong PoP key to be used by using a valid Key ID for
> > = the wrong kind of CWT."
> > >
> > > As long = as the PoP keys for different contexts are kept segregated,
> > = > Key
> ID
> > collisions or reuse cause no = problems.
> >
> > If we trust everyone to implement = things properly.  We should probably
> only
> > take = that risk if we get some other benefit from it, though.  = Jim
> mentioned
> > (off-list?) a scenario involving = giving the same client additional
> privileges, and
> > = of course we can gain some simplicity savings if we don't need = to
> > enforce global key-id uniqueness (for appropriate values = of "global").
> > So this
> may
> > = well be the right thing to do; I just don't think it's without
> = > tradeoffs
> as your
> > text seems to imply.
> = >
> > -Ben
>
> 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.

------=_NextPart_000_0134_01D40DF7.FCF058C0-- From nobody Wed Jun 27 00:32:17 2018 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 90CC6130E67; Wed, 27 Jun 2018 00:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 bwFI90Y_yBMp; Wed, 27 Jun 2018 00:32:12 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447CA130E66; Wed, 27 Jun 2018 00:32:12 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=/ydoIu5T68v/X2s0AdJNed6tAU1zf4NfVlTCDC0H3LU=; b=WQbbMOXZRxc0DbxkqQjW3aLgmoDxE2XrPVbjkjV13b174RGVaB9MWHcSJlRjlHB04XAdb3DdgNPIXWy9frpNeuVDI68yqceDZnDJQl7RFaWuaZFlLekdfUKz1ibQB77IDzHGDly9ywOYGPw2SiMeVqQIPyzzCA9FSHH9ZPJNh1M= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2750.eurprd08.prod.outlook.com (10.166.199.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.23; Wed, 27 Jun 2018 07:32:09 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%9]) with mapi id 15.20.0884.024; Wed, 27 Jun 2018 07:32:09 +0000 From: Hannes Tschofenig To: Jim Schaad , 'Benjamin Kaduk' , 'Mike Jones' CC: "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AQHUCmm7VfkGifo3LEWkTqcB1vlZy6Rsv/OAgAGd44CAALQmgIADnybQgAAXh4CAAPQgkA== Date: Wed, 27 Jun 2018 07:32:09 +0000 Message-ID: References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> In-Reply-To: <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.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: [80.92.118.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2750; 7:5XsvlNdr3WIA6CzPaioN4e+3vHDmuNBabOZofmWXIo7BG6OKsslI4SsLIJYaPBOG1TTKyZEiYe8hwUYZe93VfkQHEvV0etWeyuQ80mrwd698smd+1NUZGcH8e4dj+x64B6Ju4rN4/KDE1NGiCRKsQpOXp+vIdUmDEFvjp7bxRDlECOohP7eOpSBp3/Wxl0SXndE7WER9yUgR4OyGtIReATzqNXvwNm5wJYnmG7DFV37WtXH7T8B3fM0iIOJVPk+Z x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 15fb3ed6-427f-41c1-2cc2-08d5dc001768 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2750; x-ms-traffictypediagnostic: VI1PR0801MB2750: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(180628864354917)(89211679590171)(223705240517415)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB2750; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2750; x-forefront-prvs: 0716E70AB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(39860400002)(376002)(136003)(40434004)(189003)(199004)(13464003)(8936002)(68736007)(305945005)(74316002)(2906002)(53936002)(25786009)(6116002)(3846002)(476003)(1511001)(186003)(5250100002)(102836004)(316002)(76176011)(26005)(11346002)(446003)(486006)(66066001)(6506007)(53546011)(229853002)(6246003)(54906003)(110136005)(99286004)(86362001)(7696005)(72206003)(93886005)(256004)(105586002)(4326008)(55016002)(14454004)(9686003)(81156014)(5660300001)(478600001)(14444005)(33656002)(8676002)(2171002)(97736004)(7736002)(5024004)(81166006)(2900100001)(106356001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2750; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 0PmQ5JiFPPd0h5GuLc/fVU5aDjSp6o9gahoVRukz85jpO3ROQIONUTVVRRy9MlXyr3KqcGikWtq16PkRxvp4ApYHNivmpedCphJ3UEFxItIFgHRkBCD2Lz+emyjPFxK8nXJBz2KPxUQqzRLc7/lOtt8TQSOSo4jEh9jH9+g4JQ00qUL5rpK1JZf0Oa5J/bSfrBuQdmtiewJNXJAKLZZHQmm+Q9V7i+gVAoLk73IgS3FpINv+HBFxFQ8RPet8Jr4nJDxYNIPVpTBYAxobsSsZwdiCbyNiybiyD08yDs3++fwhWuyC2r8wEYaenGQlbXsQ0rF0DmPZGxyUyy27Yb+ciD40tqJnyyYxxpQUVdVj7NA= 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: 15fb3ed6-427f-41c1-2cc2-08d5dc001768 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2018 07:32:09.1888 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2750 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 27 Jun 2018 07:32:16 -0000 Hi Jim, It sounds like we need some high bandwidth face-to-face time on this issue = in Montreal. This is an interesting issue and IMHO reaches outside the CWT PoP document. Ciao Hannes -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: 26 June 2018 18:57 To: Hannes Tschofenig; 'Benjamin Kaduk'; 'Mike Jones' Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-poss= ession-02 Hannes, My worry is not about implementers getting this correct and picking random key ids. My worry is about an attacker seeing the key id of somebody and trying to use it either with the same or a different AS and getting a key and then getting permissions associated with the initial key that they should not be doing. This is about an attack not about getting things to generally work right. Jim > -----Original Message----- > From: Hannes Tschofenig > Sent: Tuesday, June 26, 2018 6:09 PM > To: Jim Schaad ; 'Benjamin Kaduk' > ; 'Mike Jones' > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > Hi Jim, > > you are essentially proposing that we should not directly use the key id that > is in the CWT-PoP but rather use it as input in a key derivation function= . The > details of that key derivation function are specified outside the CWT-POP > document and most likely in the context of the various profiles. > Your proposals below suggest to use, among other things, the session key as > input to that function. That sounds pretty straight forward but raises th= e > question why we fail to trust the implementer to create random key ids bu= t > then still trust them to create random keys. > > That's fine for me nevertheless. > > Ciao > Hannes > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: 24 June 2018 10:15 > To: 'Benjamin Kaduk'; 'Mike Jones' > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org; > ace@ietf.org > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > Thinking things through, I would be more comfortable with something like > the > following: > > 1. Create a confirmation called 'computed key id'. This has two basic > values: What is the computation method? What is the proof value? You can > optionally have an unprotected KID value used to filter the set of keys o= n the > RS down to a reasonable set to enumerate (hopefully one). > > 2. For RPK and TLS: Define a method called hash of SPKI which has a has= h > method as a parameter. Given that this can be computed independently by > all entities based on a Public Key value and it will be unique then you have a > key identifier that will not have collisions independent of who issues th= e > CWT. > > 3. For PSK and TLS: Define a method which takes some parameters including > the key value, the CWT issuer identity and perhaps some random string and > compute a proof of possession value on the PSK. > > 4. For PSK and OSCORE: Define a similar method the question would be wha= t > the key value is to be used but that can be defined as part of OSCORE > > When using the keys for TLS > > For RPK the key is carried in the handshake and the server/client can > generate the computed key id and compare it to what the AS distributed. > The server can identify which CWTs are applicable by either comparison of > the RPKs or the computed key id. This means you have a high probability > that you will not make a mistake and match to the wrong key. > > For PSK the identifier is carried in the handshake which is used to look up a > key value and the handshake is performed. By matching computed key ids > with the secret value one can ensure to a high probably that only CWTs that > reference the same secret are going to be used for permissions even if they > come from different AS entities. > > For OSCORE it is similar, the identifier is used to look up a key value and by > decrypting the CWT the key value is proofed. You then match computed key > ids in the same manner. > > If you really want to have something that is not cryptographically computed > and point to something else, then it makes more sense to me to reference = a > CWT issued by the same entity and say "use the same conformation method > as this CWT does". > > jim > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Saturday, June 23, 2018 11:30 PM > > To: Mike Jones > > Cc: Hannes Tschofenig ; Jim Schaad > > ; > > draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > ace@ietf.org > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > See my note just now proposing this text to Jim: > > > > > > "Likewise, if PoP keys are used for multiple different kinds of CWTs > > > in > an > > application and the PoP keys are identified by Key IDs, care must be > > taken > to > > keep the keys for the different kinds of CWTs segregated so that an > attacker > > cannot cause the wrong PoP key to be used by using a valid Key ID for > > the wrong kind of CWT." > > > > > > As long as the PoP keys for different contexts are kept segregated, > > > Key > ID > > collisions or reuse cause no problems. > > > > If we trust everyone to implement things properly. We should probably > only > > take that risk if we get some other benefit from it, though. Jim > mentioned > > (off-list?) a scenario involving giving the same client additional > privileges, and > > of course we can gain some simplicity savings if we don't need to > > enforce global key-id uniqueness (for appropriate values of "global"). > > So this > may > > well be the right thing to do; I just don't think it's without > > tradeoffs > as your > > text seems to imply. > > > > -Ben > > 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. 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 Jun 27 00:32:30 2018 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 824A6130E87; Wed, 27 Jun 2018 00:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 I_NDT7VWAdZ7; Wed, 27 Jun 2018 00:32:12 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0047.outbound.protection.outlook.com [104.47.2.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD76130DFA; Wed, 27 Jun 2018 00:32:10 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=l1LA7lBqGox+6+jsWehONH/I53nR2EMgMLEdez3dpro=; b=TkfBu7ucJz//2HVhYbmQBQ8uDcAjFON2pop91H5hirIV3mlAXeagB0TJ1yO6QGU6zUCGCVE2anPJJFBDCmvtYeSVx+kl3p7AYv50MYBmxutb8X7kD6mvHlOwDRfS/ZxJSIKMShqNmRtYryzUoBg8wiOAHgOL12xKX9ZAc9I2xgc= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1677.eurprd08.prod.outlook.com (10.168.66.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.23; Wed, 27 Jun 2018 07:32:08 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%9]) with mapi id 15.20.0884.024; Wed, 27 Jun 2018 07:32:08 +0000 From: Hannes Tschofenig To: Samuel Erdtman , Jim Schaad CC: Benjamin Kaduk , Mike Jones , "draft-ietf-ace-cwt-proof-of-possession@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Thread-Index: AQHUCmm7VfkGifo3LEWkTqcB1vlZy6Rsv/OAgAGd44CAALQmgIADnybQgAAXh4CAAN+nAIAAERaA Date: Wed, 27 Jun 2018 07:32:08 +0000 Message-ID: References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> 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.118.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1677; 7:yIKdRPm92005tZ9EGb7Fgd6CD5e2C4yHCRx9bCJ5LdIs06I9WnQki5mowUWow4qdml+jgf7j1IejtchJrm8j22+/m6H+gMw5q8sHQLfVwPG4bBoIlvvJEq+DDCkym1tRRv2bU90CH1U2FmM21EDmCMhdHmpMiUOO7tSqn7qp220QUzVXAMSXB3Mk5QiVTDZAm4pQK+q2KK5vtIkaYab99SlYBiHXpAaRYf4MMZrnHGRVGAUrDjcRkJ+2FGAJYfT/ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 14141c77-ac73-423e-0b68-08d5dc0016e5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1677; x-ms-traffictypediagnostic: VI1PR0801MB1677: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(180628864354917)(89211679590171)(192374486261705)(223705240517415)(263433327382760)(21748063052155)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1677; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1677; x-forefront-prvs: 0716E70AB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(376002)(346002)(39860400002)(199004)(189003)(13464003)(40434004)(54906003)(97736004)(55016002)(9686003)(68736007)(236005)(6506007)(76176011)(2900100001)(45080400002)(54896002)(102836004)(53546011)(72206003)(790700001)(105586002)(186003)(7696005)(5024004)(14444005)(3846002)(6116002)(5660300001)(86362001)(5250100002)(26005)(478600001)(110136005)(14454004)(33656002)(229853002)(53936002)(25786009)(81166006)(8936002)(8676002)(4326008)(6306002)(316002)(106356001)(256004)(11346002)(476003)(66066001)(446003)(81156014)(99286004)(93886005)(74316002)(486006)(7736002)(6246003)(2906002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1677; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4APldCE0q3AFiiD4V+YUkl92i+TJu3lehWkMD/uwCuiYBB4XTLa0zZYn8/FcaDP+MKRSA5I9xKkVhpbC0iehCa8aD690CkPHdHdiKGd3ABpSBNlLISu5MERE4v6Mcwb0vtjbbHELI5US2/AtR1YBNoAa7bPftZH7BnDs8+cvukEAnQSpQUuee6Xol2FABjYpMS2SGAvU0fxIPXV+FRNuNuYE7FGGWEIDZ0g8jAg9ZwRLB7N8yJZheoko070uvvp5t2v1KEgkLuzlC2MIIKHVbyeFEp8nbf6chXQMOqYXvzH2a+Eco2FTUgbypiCNFYgs8+717y3M8RCAGeR27O6MHJii95Fz6SrBylNjzvru0UE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112509D0220E8DA6A8AEDC2FA480VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14141c77-ac73-423e-0b68-08d5dc0016e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2018 07:32:08.3763 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1677 Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 27 Jun 2018 07:32:17 -0000 --_000_VI1PR0801MB2112509D0220E8DA6A8AEDC2FA480VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FtdWVsLCBKaW0sDQoNCldlIGhhdmUgdHdvIGNhc2VzIGluIEFDRS1PQXV0aDoNCg0KDQoxKSAg ICAgIENsaWVudCBwcm92aWRlcyBhIGtleSAob3IgYSByZWZlcmVuY2UgdG8gYSBrZXkpIHRvIHRo ZSBBUy4gSXQgd2FudHMgdGhlIEFTIHRvIGluY2x1ZGUgdGhhdCBrZXkgaW50byB0aGUgUG9QIHRv a2VuLiBUaGUga2V5IGlzIHRoZSBsb25nIHZlcnNpb24gb2YgdGhlIGtleSBpZCouDQoNCjIpICAg ICAgQ2xpZW50IGFza3MgdGhlIEFTIHRvIGdldCBhIHRva2VuLiBJbiB0aGlzIGNhc2UgdGhlIEFT IGNyZWF0ZXMgYSBrZXkgYW5kIHBsYWNlcyB0aGF0IGtleSBvciBrZXkgaWQgaW4gdGhlIFBvUCB0 b2tlbi4NCg0KV2Ugc2VlbSB0byBiZSB3b3JyaWVkIHRoYXQgdGhlc2Uga2V5cyAvIGtleSBpZHMg YXJlIG5vdCB1bmlxdWUgb3ZlciB0aGUgbGlmZXRpbWUgb2YgdGhlIHRva2Vucy4NClRoZSBBQ0Ut T0F1dGggZG9jdW1lbnQgc2hvdWxkIHNheSB0aGF0IHRoZSBBUyBoYXMgdG8gbWFrZSBzdXJlIHRo YXQga2V5cyBhbmQga2V5IGlkcyBhcmUgbm90IHJlLXVzZWQgb3ZlciB0aGUgbGlmZXRpbWUgb2Yg YSBQb1AgdG9rZW4sIHVubGVzcyB0aGlzIGlzIGEgZGVzaXJlZCBiZWhhdmlvdXIuDQpJIGRvbuKA mXQgdGhpbmsgdGhhdCB0aGUgQ1dUIFBvUCB0b2tlbiBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gZGlz Y3VzcyB0aGlzIHRvcGljLg0KDQpDaWFvDQpIYW5uZXMNCg0KKjogSGVyZSBpcyB3aGF0IHRoZSBk cmFmdCBzYXlzOg0KDQrigJwNClRoZSBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleSBjYW4gYWxzbyBi ZSBpZGVudGlmaWVkIGJ5IHRoZSB1c2Ugb2YgYQ0KICAgS2V5IElEIGluc3RlYWQgb2YgY29tbXVu aWNhdGluZyB0aGUgYWN0dWFsIGtleSwgcHJvdmlkZWQgdGhlDQogICByZWNpcGllbnQgaXMgYWJs ZSB0byBvYnRhaW4gdGhlIGlkZW50aWZpZWQga2V5IHVzaW5nIHRoZSBLZXkgSUQuDQrigJwNCg0K RnJvbTogU2FtdWVsIEVyZHRtYW4gW21haWx0bzplcmR0bWFuQHNwb3RpZnkuY29tXQ0KU2VudDog MjcgSnVuZSAyMDE4IDA4OjE4DQpUbzogSmltIFNjaGFhZA0KQ2M6IEhhbm5lcyBUc2Nob2Zlbmln OyBCZW5qYW1pbiBLYWR1azsgTWlrZSBKb25lczsgZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9m LXBvc3Nlc3Npb25AaWV0Zi5vcmc7IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIEtl eSBJRHMgLi4uIFJFOiBXR0xDIG9uIGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNz aW9uLTAyDQoNCkppbSwgYXJlIHlvdSBzYXlpbmcgdGhhdCBpZiB0aGUgY2xpZW50IGNhbiBwaWNr IHRoZSBrZXkgaWRlbnRpZmllciBhbmQgaWYgaXQgaGFzIHNlZW4gYSBrZXkgaWRlbnRpZmllciBv ZiBhbm90aGVyIGNsaWVudCBpdCBjb3VsZCByZXF1ZXN0IGEgUG9QIHRva2VuIHdpdGggdGhlIG9i c2VydmVkIGtleS1pZCBhbmQgdGhlIG9ic2VydmVkIHN1YmplY3QgYnV0IHdpdGggYW4gbmV3IGtl eS4NCkkgZ3Vlc3MgdGhpcyBpcyBhIHBvdGVudGlhbCBzY2VuYXJpbyB0aGF0IGNvdWxkIGJlIHdv cnRoIG1lbnRpb25pbmcgaW4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQoNCklmIHdlIGxvb2sg YXQgQUNFLU9BdXRoIHRoZXJlIGFyZSBhcyBmYXIgYXMgSSBjYW4gdGVsbCBhIGZldyB0aGluZ3Mg dGhhdCBtYWtlcyB0aGlzIGEgaGFyZCBhdHRhY2sgdG8gZG8uDQoNCldoZW4gdGhlIGNsaWVudCBt YWtlcyB0aGUgdG9rZW4gcmVxdWVzdCBpdCBpcyBhdXRoZW50aWNhdGVkLg0KDQpBbmQgd2l0aCB0 aGUgc3ViamVjdCBiZWluZyB0aGUgYXV0aGVudGljYXRlZCBjbGllbnQgY2Fubm90IGNvbnRyb2wg d2hhdCBnb2VzIGludG8gdGhlIGN3dCBhcyBzdWJqZWN0DQoNClNpbmNlIHRoZSBjd3Qgd2l0aCB0 aGUgUG9QIGtleSBpcyBzaWduZWQgdGhlcmUgaXMgbm8gd2F5IGZvciB0aGUgYXR0YWNraW5nIGNs aWVudCB0byByZXRyby1maXQgdGhlIHRva2VuIHRvIHN1aXQgaXRzIG5lZWRzIGUuZy4gY2hhbmdl IHN1YmplY3Qgb3Iga2V5LWlkLg0KDQpGaW5hbGx5IEkgdGhpbmsgaXQgaXMgcHJlZmVyYWJsZSBp ZiB0aGUgc2VydmVyIHNlbGVjdHMga2V5IGlkZW50aWZpZXIuDQoNCkJlc3QgcmVnYXJkcw0KLy9T YW11ZWwNCg0KDQpPbiBUdWUsIDI2IEp1biAyMDE4IGF0IDE4OjU3LCBKaW0gU2NoYWFkIDxpZXRm QGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4gd3JvdGU6 DQpIYW5uZXMsDQoNCk15IHdvcnJ5IGlzIG5vdCBhYm91dCBpbXBsZW1lbnRlcnMgZ2V0dGluZyB0 aGlzIGNvcnJlY3QgYW5kIHBpY2tpbmcgcmFuZG9tDQprZXkgaWRzLiAgTXkgd29ycnkgaXMgYWJv dXQgYW4gYXR0YWNrZXIgc2VlaW5nIHRoZSBrZXkgaWQgb2Ygc29tZWJvZHkgYW5kDQp0cnlpbmcg dG8gdXNlIGl0IGVpdGhlciB3aXRoIHRoZSBzYW1lIG9yIGEgZGlmZmVyZW50IEFTIGFuZCBnZXR0 aW5nIGEga2V5DQphbmQgdGhlbiBnZXR0aW5nIHBlcm1pc3Npb25zIGFzc29jaWF0ZWQgd2l0aCB0 aGUgaW5pdGlhbCBrZXkgdGhhdCB0aGV5DQpzaG91bGQgbm90IGJlIGRvaW5nLg0KDQpUaGlzIGlz IGFib3V0IGFuIGF0dGFjayBub3QgYWJvdXQgZ2V0dGluZyB0aGluZ3MgdG8gZ2VuZXJhbGx5IHdv cmsgcmlnaHQuDQoNCkppbQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhh bm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+Pg0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDI2LCAyMDE4 IDY6MDkgUE0NCj4gVG86IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRv OmlldGZAYXVndXN0Y2VsbGFycy5jb20+PjsgJ0JlbmphbWluIEthZHVrJw0KPiA8a2FkdWtAbWl0 LmVkdTxtYWlsdG86a2FkdWtAbWl0LmVkdT4+OyAnTWlrZSBKb25lcycgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCj4gQ2M6 IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uQGlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbkBpZXRmLm9yZz47IGFjZUBpZXRm Lm9yZzxtYWlsdG86YWNlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogW0FjZV0gS2V5IElEcyAu Li4gUkU6IFdHTEMgb24gZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLQ0KPiBwb3NzZXNzaW9u LTAyDQo+DQo+IEhpIEppbSwNCj4NCj4geW91IGFyZSBlc3NlbnRpYWxseSBwcm9wb3NpbmcgdGhh dCB3ZSBzaG91bGQgbm90IGRpcmVjdGx5IHVzZSB0aGUga2V5IGlkDQp0aGF0DQo+IGlzIGluIHRo ZSBDV1QtUG9QIGJ1dCByYXRoZXIgdXNlIGl0IGFzIGlucHV0IGluIGEga2V5IGRlcml2YXRpb24g ZnVuY3Rpb24uDQpUaGUNCj4gZGV0YWlscyBvZiB0aGF0IGtleSBkZXJpdmF0aW9uIGZ1bmN0aW9u IGFyZSBzcGVjaWZpZWQgb3V0c2lkZSB0aGUgQ1dULVBPUA0KPiBkb2N1bWVudCBhbmQgbW9zdCBs aWtlbHkgaW4gdGhlIGNvbnRleHQgb2YgdGhlIHZhcmlvdXMgcHJvZmlsZXMuDQo+IFlvdXIgcHJv cG9zYWxzIGJlbG93IHN1Z2dlc3QgdG8gdXNlLCBhbW9uZyBvdGhlciB0aGluZ3MsIHRoZSBzZXNz aW9uIGtleQ0KYXMNCj4gaW5wdXQgdG8gdGhhdCBmdW5jdGlvbi4gVGhhdCBzb3VuZHMgcHJldHR5 IHN0cmFpZ2h0IGZvcndhcmQgYnV0IHJhaXNlcyB0aGUNCj4gcXVlc3Rpb24gd2h5IHdlIGZhaWwg dG8gdHJ1c3QgdGhlIGltcGxlbWVudGVyIHRvIGNyZWF0ZSByYW5kb20ga2V5IGlkcyBidXQNCj4g dGhlbiBzdGlsbCB0cnVzdCB0aGVtIHRvIGNyZWF0ZSByYW5kb20ga2V5cy4NCj4NCj4gVGhhdCdz IGZpbmUgZm9yIG1lIG5ldmVydGhlbGVzcy4NCj4NCj4gQ2lhbw0KPiBIYW5uZXMNCj4NCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmltIFNjaGFhZCBbbWFpbHRvOmlldGZA YXVndXN0Y2VsbGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+XQ0KPiBTZW50 OiAyNCBKdW5lIDIwMTggMTA6MTUNCj4gVG86ICdCZW5qYW1pbiBLYWR1ayc7ICdNaWtlIEpvbmVz Jw0KPiBDYzogSGFubmVzIFRzY2hvZmVuaWc7IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1w b3NzZXNzaW9uQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9z c2Vzc2lvbkBpZXRmLm9yZz47DQo+IGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPg0K PiBTdWJqZWN0OiBSRTogW0FjZV0gS2V5IElEcyAuLi4gUkU6IFdHTEMgb24gZHJhZnQtaWV0Zi1h Y2UtY3d0LXByb29mLW9mLQ0KPiBwb3NzZXNzaW9uLTAyDQo+DQo+IFRoaW5raW5nIHRoaW5ncyB0 aHJvdWdoLCBJIHdvdWxkIGJlIG1vcmUgY29tZm9ydGFibGUgd2l0aCBzb21ldGhpbmcgbGlrZQ0K PiB0aGUNCj4gZm9sbG93aW5nOg0KPg0KPiAxLiAgQ3JlYXRlIGEgY29uZmlybWF0aW9uIGNhbGxl ZCAnY29tcHV0ZWQga2V5IGlkJy4gIFRoaXMgaGFzIHR3byBiYXNpYw0KPiB2YWx1ZXM6ICBXaGF0 IGlzIHRoZSBjb21wdXRhdGlvbiBtZXRob2Q/ICBXaGF0IGlzIHRoZSBwcm9vZiB2YWx1ZT8gIFlv dQ0KY2FuDQo+IG9wdGlvbmFsbHkgaGF2ZSBhbiB1bnByb3RlY3RlZCBLSUQgdmFsdWUgdXNlZCB0 byBmaWx0ZXIgdGhlIHNldCBvZiBrZXlzIG9uDQp0aGUNCj4gUlMgZG93biB0byBhIHJlYXNvbmFi bGUgc2V0IHRvIGVudW1lcmF0ZSAoaG9wZWZ1bGx5IG9uZSkuDQo+DQo+IDIuICBGb3IgUlBLIGFu ZCBUTFM6ICBEZWZpbmUgYSBtZXRob2QgY2FsbGVkIGhhc2ggb2YgU1BLSSB3aGljaCBoYXMgYSBo YXNoDQo+IG1ldGhvZCBhcyBhIHBhcmFtZXRlci4gIEdpdmVuIHRoYXQgdGhpcyBjYW4gYmUgY29t cHV0ZWQgaW5kZXBlbmRlbnRseSBieQ0KPiBhbGwgZW50aXRpZXMgYmFzZWQgb24gYSBQdWJsaWMg S2V5IHZhbHVlIGFuZCBpdCB3aWxsIGJlIHVuaXF1ZSB0aGVuIHlvdQ0KaGF2ZSBhDQo+IGtleSBp ZGVudGlmaWVyIHRoYXQgd2lsbCBub3QgaGF2ZSBjb2xsaXNpb25zIGluZGVwZW5kZW50IG9mIHdo byBpc3N1ZXMgdGhlDQo+IENXVC4NCj4NCj4gMy4gIEZvciBQU0sgYW5kIFRMUzogIERlZmluZSBh IG1ldGhvZCB3aGljaCB0YWtlcyBzb21lIHBhcmFtZXRlcnMNCmluY2x1ZGluZw0KPiB0aGUga2V5 IHZhbHVlLCB0aGUgQ1dUIGlzc3VlciBpZGVudGl0eSBhbmQgcGVyaGFwcyBzb21lIHJhbmRvbSBz dHJpbmcgYW5kDQo+IGNvbXB1dGUgYSBwcm9vZiBvZiBwb3NzZXNzaW9uIHZhbHVlIG9uIHRoZSBQ U0suDQo+DQo+IDQuICBGb3IgUFNLIGFuZCBPU0NPUkU6IERlZmluZSBhIHNpbWlsYXIgbWV0aG9k IHRoZSBxdWVzdGlvbiB3b3VsZCBiZSB3aGF0DQo+IHRoZSBrZXkgdmFsdWUgaXMgdG8gYmUgdXNl ZCBidXQgdGhhdCBjYW4gYmUgZGVmaW5lZCBhcyBwYXJ0IG9mIE9TQ09SRQ0KPg0KPiBXaGVuIHVz aW5nIHRoZSBrZXlzIGZvciBUTFMNCj4NCj4gRm9yIFJQSyB0aGUga2V5IGlzIGNhcnJpZWQgaW4g dGhlIGhhbmRzaGFrZSBhbmQgdGhlIHNlcnZlci9jbGllbnQgY2FuDQo+IGdlbmVyYXRlIHRoZSBj b21wdXRlZCBrZXkgaWQgYW5kIGNvbXBhcmUgaXQgdG8gd2hhdCB0aGUgQVMgZGlzdHJpYnV0ZWQu DQo+IFRoZSBzZXJ2ZXIgY2FuIGlkZW50aWZ5IHdoaWNoIENXVHMgYXJlIGFwcGxpY2FibGUgYnkg ZWl0aGVyIGNvbXBhcmlzb24gb2YNCj4gdGhlIFJQS3Mgb3IgdGhlIGNvbXB1dGVkIGtleSBpZC4g IFRoaXMgbWVhbnMgeW91IGhhdmUgYSBoaWdoIHByb2JhYmlsaXR5DQo+IHRoYXQgeW91IHdpbGwg bm90IG1ha2UgYSBtaXN0YWtlIGFuZCBtYXRjaCB0byB0aGUgd3Jvbmcga2V5Lg0KPg0KPiBGb3Ig UFNLIHRoZSBpZGVudGlmaWVyIGlzIGNhcnJpZWQgaW4gdGhlIGhhbmRzaGFrZSB3aGljaCBpcyB1 c2VkIHRvIGxvb2sNCnVwIGENCj4ga2V5IHZhbHVlIGFuZCB0aGUgaGFuZHNoYWtlIGlzIHBlcmZv cm1lZC4gIEJ5IG1hdGNoaW5nIGNvbXB1dGVkIGtleSBpZHMNCj4gd2l0aCB0aGUgc2VjcmV0IHZh bHVlIG9uZSBjYW4gZW5zdXJlIHRvIGEgaGlnaCBwcm9iYWJseSB0aGF0IG9ubHkgQ1dUcw0KdGhh dA0KPiByZWZlcmVuY2UgdGhlIHNhbWUgc2VjcmV0IGFyZSBnb2luZyB0byBiZSB1c2VkIGZvciBw ZXJtaXNzaW9ucyBldmVuIGlmDQp0aGV5DQo+IGNvbWUgZnJvbSBkaWZmZXJlbnQgQVMgZW50aXRp ZXMuDQo+DQo+IEZvciBPU0NPUkUgaXQgaXMgc2ltaWxhciwgdGhlIGlkZW50aWZpZXIgaXMgdXNl ZCB0byBsb29rIHVwIGEga2V5IHZhbHVlDQphbmQgYnkNCj4gZGVjcnlwdGluZyB0aGUgQ1dUIHRo ZSBrZXkgdmFsdWUgaXMgcHJvb2ZlZC4gIFlvdSB0aGVuIG1hdGNoIGNvbXB1dGVkIGtleQ0KPiBp ZHMgaW4gdGhlIHNhbWUgbWFubmVyLg0KPg0KPiBJZiB5b3UgcmVhbGx5IHdhbnQgdG8gaGF2ZSBz b21ldGhpbmcgdGhhdCBpcyBub3QgY3J5cHRvZ3JhcGhpY2FsbHkNCmNvbXB1dGVkDQo+IGFuZCBw b2ludCB0byBzb21ldGhpbmcgZWxzZSwgdGhlbiBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIG1lIHRv IHJlZmVyZW5jZSBhDQo+IENXVCBpc3N1ZWQgYnkgdGhlIHNhbWUgZW50aXR5IGFuZCBzYXkgInVz ZSB0aGUgc2FtZSBjb25mb3JtYXRpb24gbWV0aG9kDQo+IGFzIHRoaXMgQ1dUIGRvZXMiLg0KPg0K PiBqaW0NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJlbmph bWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PG1haWx0bzprYWR1a0BtaXQuZWR1Pj4NCj4gPiBTZW50 OiBTYXR1cmRheSwgSnVuZSAyMywgMjAxOCAxMTozMCBQTQ0KPiA+IFRvOiBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4+DQo+ID4gQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0u Y29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj47IEppbSBTY2hhYWQNCj4gPiA8 aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+Ow0K PiA+IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uQGlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbkBpZXRmLm9yZz47DQo+ID4g YWNlQGlldGYub3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFtBY2Vd IEtleSBJRHMgLi4uIFJFOiBXR0xDIG9uDQo+ID4gZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9m LQ0KPiA+IHBvc3Nlc3Npb24tMDINCj4gPg0KPiA+IE9uIEZyaSwgSnVuIDIyLCAyMDE4IGF0IDA4 OjQ4OjM1UE0gKzAwMDAsIE1pa2UgSm9uZXMgd3JvdGU6DQo+ID4gPiBTZWUgbXkgbm90ZSBqdXN0 IG5vdyBwcm9wb3NpbmcgdGhpcyB0ZXh0IHRvIEppbToNCj4gPiA+DQo+ID4gPiAiTGlrZXdpc2Us IGlmIFBvUCBrZXlzIGFyZSB1c2VkIGZvciBtdWx0aXBsZSBkaWZmZXJlbnQga2luZHMgb2YgQ1dU cw0KPiA+ID4gaW4NCj4gYW4NCj4gPiBhcHBsaWNhdGlvbiBhbmQgdGhlIFBvUCBrZXlzIGFyZSBp ZGVudGlmaWVkIGJ5IEtleSBJRHMsIGNhcmUgbXVzdCBiZQ0KPiA+IHRha2VuDQo+IHRvDQo+ID4g a2VlcCB0aGUga2V5cyBmb3IgdGhlIGRpZmZlcmVudCBraW5kcyBvZiBDV1RzIHNlZ3JlZ2F0ZWQg c28gdGhhdCBhbg0KPiBhdHRhY2tlcg0KPiA+IGNhbm5vdCBjYXVzZSB0aGUgd3JvbmcgUG9QIGtl eSB0byBiZSB1c2VkIGJ5IHVzaW5nIGEgdmFsaWQgS2V5IElEIGZvcg0KPiA+IHRoZSB3cm9uZyBr aW5kIG9mIENXVC4iDQo+ID4gPg0KPiA+ID4gQXMgbG9uZyBhcyB0aGUgUG9QIGtleXMgZm9yIGRp ZmZlcmVudCBjb250ZXh0cyBhcmUga2VwdCBzZWdyZWdhdGVkLA0KPiA+ID4gS2V5DQo+IElEDQo+ ID4gY29sbGlzaW9ucyBvciByZXVzZSBjYXVzZSBubyBwcm9ibGVtcy4NCj4gPg0KPiA+IElmIHdl IHRydXN0IGV2ZXJ5b25lIHRvIGltcGxlbWVudCB0aGluZ3MgcHJvcGVybHkuICBXZSBzaG91bGQg cHJvYmFibHkNCj4gb25seQ0KPiA+IHRha2UgdGhhdCByaXNrIGlmIHdlIGdldCBzb21lIG90aGVy IGJlbmVmaXQgZnJvbSBpdCwgdGhvdWdoLiAgSmltDQo+IG1lbnRpb25lZA0KPiA+IChvZmYtbGlz dD8pIGEgc2NlbmFyaW8gaW52b2x2aW5nIGdpdmluZyB0aGUgc2FtZSBjbGllbnQgYWRkaXRpb25h bA0KPiBwcml2aWxlZ2VzLCBhbmQNCj4gPiBvZiBjb3Vyc2Ugd2UgY2FuIGdhaW4gc29tZSBzaW1w bGljaXR5IHNhdmluZ3MgaWYgd2UgZG9uJ3QgbmVlZCB0bw0KPiA+IGVuZm9yY2UgZ2xvYmFsIGtl eS1pZCB1bmlxdWVuZXNzIChmb3IgYXBwcm9wcmlhdGUgdmFsdWVzIG9mICJnbG9iYWwiKS4NCj4g PiBTbyB0aGlzDQo+IG1heQ0KPiA+IHdlbGwgYmUgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvOyBJIGp1 c3QgZG9uJ3QgdGhpbmsgaXQncyB3aXRob3V0DQo+ID4gdHJhZGVvZmZzDQo+IGFzIHlvdXINCj4g PiB0ZXh0IHNlZW1zIHRvIGltcGx5Lg0KPiA+DQo+ID4gLUJlbg0KPg0KPiBJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZQ0K PiBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50LA0KPiBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8NCmFueQ0KPiBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluDQphbnkNCj4gbWVkaXVtLiBUaGFuayB5b3UuDQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB2112509D0220E8DA6A8AEDC2FA480VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207 DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjE4MjMzNDYzMDE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwODc5ODU5MiAxMzQ4MDc1NjkgMTM0ODA3NTc3IDEzNDgw NzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEz NDgwNzU3OTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TYW11ZWwsIEppbSwNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+V2UgaGF2ZSB0d28gY2FzZXMgaW4gQUNFLU9BdXRoOg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2xpZW50IHByb3ZpZGVzIGEga2V5IChv ciBhIHJlZmVyZW5jZSB0byBhIGtleSkgdG8gdGhlIEFTLiBJdCB3YW50cyB0aGUgQVMgdG8gaW5j bHVkZSB0aGF0IGtleSBpbnRvIHRoZSBQb1AgdG9rZW4uIFRoZSBrZXkgaXMgdGhlIGxvbmcgdmVy c2lvbiBvZg0KIHRoZSBrZXkgaWQqLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNsaWVudCBhc2tzIHRoZSBB UyB0byBnZXQgYSB0b2tlbi4gSW4gdGhpcyBjYXNlIHRoZSBBUyBjcmVhdGVzIGEga2V5IGFuZCBw bGFjZXMgdGhhdCBrZXkgb3Iga2V5IGlkIGluIHRoZSBQb1AgdG9rZW4uDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldl IHNlZW0gdG8gYmUgd29ycmllZCB0aGF0IHRoZXNlIGtleXMgLyBrZXkgaWRzIGFyZSBub3QgdW5p cXVlIG92ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSB0b2tlbnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIEFDRS1PQXV0aCBkb2N1bWVudCBzaG91bGQgc2F5IHRoYXQgdGhlIEFT IGhhcyB0byBtYWtlIHN1cmUgdGhhdCBrZXlzIGFuZCBrZXkgaWRzIGFyZSBub3QgcmUtdXNlZCBv dmVyIHRoZSBsaWZldGltZSBvZiBhIFBvUCB0b2tlbiwgdW5sZXNzIHRoaXMgaXMgYSBkZXNpcmVk DQogYmVoYXZpb3VyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRo aW5rIHRoYXQgdGhlIENXVCBQb1AgdG9rZW4gaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIGRpc2N1c3Mg dGhpcyB0b3BpYy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2lhbzxicj4NCkhhbm5lczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KjogSGVy ZSBpcyB3aGF0IHRoZSBkcmFmdCBzYXlzOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhlIHBy b29mLW9mLXBvc3Nlc3Npb24ga2V5IGNhbiBhbHNvIGJlIGlkZW50aWZpZWQgYnkgdGhlIHVzZSBv ZiBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBLZXkgSUQgaW5zdGVhZCBvZiBjb21tdW5pY2F0aW5n IHRoZSBhY3R1YWwga2V5LCBwcm92aWRlZCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJlY2lw aWVudCBpcyBhYmxlIHRvIG9idGFpbiB0aGUgaWRlbnRpZmllZCBrZXkgdXNpbmcgdGhlIEtleSBJ RC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2FtdWVsIEVyZHRtYW4gW21haWx0bzplcmR0bWFuQHNw b3RpZnkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI3IEp1bmUgMjAxOCAwODoxODxicj4NCjxi PlRvOjwvYj4gSmltIFNjaGFhZDxicj4NCjxiPkNjOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc7IEJl bmphbWluIEthZHVrOyBNaWtlIEpvbmVzOyBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9z c2Vzc2lvbkBpZXRmLm9yZzsgYWNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb QWNlXSBLZXkgSURzIC4uLiBSRTogV0dMQyBvbiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2Yt cG9zc2Vzc2lvbi0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5KaW0sIGFyZSB5b3Ugc2F5aW5nIHRoYXQgaWYgdGhlIGNsaWVudCBj YW4gcGljayB0aGUga2V5IGlkZW50aWZpZXIgYW5kIGlmIGl0IGhhcyBzZWVuIGEga2V5IGlkZW50 aWZpZXIgb2YgYW5vdGhlciBjbGllbnQgaXQgY291bGQgcmVxdWVzdCBhIFBvUCB0b2tlbiB3aXRo IHRoZSBvYnNlcnZlZCBrZXktaWQgYW5kIHRoZSBvYnNlcnZlZCBzdWJqZWN0IGJ1dCB3aXRoDQog YW4gbmV3IGtleS4gPGJyPg0KSSBndWVzcyB0aGlzIGlzIGEgcG90ZW50aWFsIHNjZW5hcmlvIHRo YXQgY291bGQgYmUgd29ydGggbWVudGlvbmluZyBpbiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy48 YnI+DQo8YnI+DQpJZiB3ZSBsb29rIGF0IEFDRS1PQXV0aCB0aGVyZSBhcmUgYXMgZmFyIGFzIEkg Y2FuIHRlbGwgYSBmZXcgdGhpbmdzIHRoYXQgbWFrZXMgdGhpcyBhIGhhcmQgYXR0YWNrIHRvIGRv Ljxicj4NCjxicj4NCldoZW4gdGhlIGNsaWVudCBtYWtlcyB0aGUgdG9rZW4gcmVxdWVzdCBpdCBp cyBhdXRoZW50aWNhdGVkLjxicj4NCjxicj4NCkFuZCB3aXRoIHRoZSBzdWJqZWN0IGJlaW5nIHRo ZSBhdXRoZW50aWNhdGVkIGNsaWVudCBjYW5ub3QgY29udHJvbCB3aGF0IGdvZXMgaW50byB0aGUg Y3d0IGFzIHN1YmplY3Q8YnI+DQo8YnI+DQpTaW5jZSB0aGUgY3d0IHdpdGggdGhlIFBvUCBrZXkg aXMgc2lnbmVkIHRoZXJlIGlzIG5vIHdheSBmb3IgdGhlIGF0dGFja2luZyBjbGllbnQgdG8gcmV0 cm8tZml0IHRoZSB0b2tlbiB0byBzdWl0IGl0cyBuZWVkcyBlLmcuIGNoYW5nZSBzdWJqZWN0IG9y IGtleS1pZC48YnI+DQo8YnI+DQpGaW5hbGx5IEkgdGhpbmsgaXQgaXMgcHJlZmVyYWJsZSBpZiB0 aGUgc2VydmVyIHNlbGVjdHMga2V5IGlkZW50aWZpZXIuIDxicj4NCjxicj4NCkJlc3QgcmVnYXJk czxicj4NCi8vU2FtdWVsPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgMjYgSnVuIDIwMTggYXQgMTg6NTcs IEppbSBTY2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIj5p ZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPkhhbm5lcyw8YnI+DQo8YnI+DQpNeSB3b3JyeSBpcyBub3QgYWJvdXQgaW1wbGVt ZW50ZXJzIGdldHRpbmcgdGhpcyBjb3JyZWN0IGFuZCBwaWNraW5nIHJhbmRvbTxicj4NCmtleSBp ZHMuJm5ic3A7IE15IHdvcnJ5IGlzIGFib3V0IGFuIGF0dGFja2VyIHNlZWluZyB0aGUga2V5IGlk IG9mIHNvbWVib2R5IGFuZDxicj4NCnRyeWluZyB0byB1c2UgaXQgZWl0aGVyIHdpdGggdGhlIHNh bWUgb3IgYSBkaWZmZXJlbnQgQVMgYW5kIGdldHRpbmcgYSBrZXk8YnI+DQphbmQgdGhlbiBnZXR0 aW5nIHBlcm1pc3Npb25zIGFzc29jaWF0ZWQgd2l0aCB0aGUgaW5pdGlhbCBrZXkgdGhhdCB0aGV5 PGJyPg0Kc2hvdWxkIG5vdCBiZSBkb2luZy48YnI+DQo8YnI+DQpUaGlzIGlzIGFib3V0IGFuIGF0 dGFjayBub3QgYWJvdXQgZ2V0dGluZyB0aGluZ3MgdG8gZ2VuZXJhbGx5IHdvcmsgcmlnaHQuPGJy Pg0KPGJyPg0KSmltPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsgRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0 bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hv ZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBKdW5lIDI2LCAy MDE4IDY6MDkgUE08YnI+DQomZ3Q7IFRvOiBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86 aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYXVndXN0Y2VsbGFy cy5jb208L2E+Jmd0OzsgJ0JlbmphbWluIEthZHVrJzxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzprYWR1a0BtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+a2FkdWtAbWl0LmVkdTwvYT4mZ3Q7 OyAnTWlrZSBKb25lcycgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0 Ozxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Yt b2YtcG9zc2Vzc2lvbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0Zi1hY2Ut Y3d0LXByb29mLW9mLXBvc3Nlc3Npb25AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86YWNl QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQphY2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBT dWJqZWN0OiBSRTogW0FjZV0gS2V5IElEcyAuLi4gUkU6IFdHTEMgb24gZHJhZnQtaWV0Zi1hY2Ut Y3d0LXByb29mLW9mLTxicj4NCiZndDsgcG9zc2Vzc2lvbi0wMjxicj4NCiZndDsgPGJyPg0KJmd0 OyBIaSBKaW0sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHlvdSBhcmUgZXNzZW50aWFsbHkgcHJvcG9z aW5nIHRoYXQgd2Ugc2hvdWxkIG5vdCBkaXJlY3RseSB1c2UgdGhlIGtleSBpZDxicj4NCnRoYXQ8 YnI+DQomZ3Q7IGlzIGluIHRoZSBDV1QtUG9QIGJ1dCByYXRoZXIgdXNlIGl0IGFzIGlucHV0IGlu IGEga2V5IGRlcml2YXRpb24gZnVuY3Rpb24uPGJyPg0KVGhlPGJyPg0KJmd0OyBkZXRhaWxzIG9m IHRoYXQga2V5IGRlcml2YXRpb24gZnVuY3Rpb24gYXJlIHNwZWNpZmllZCBvdXRzaWRlIHRoZSBD V1QtUE9QPGJyPg0KJmd0OyBkb2N1bWVudCBhbmQgbW9zdCBsaWtlbHkgaW4gdGhlIGNvbnRleHQg b2YgdGhlIHZhcmlvdXMgcHJvZmlsZXMuPGJyPg0KJmd0OyBZb3VyIHByb3Bvc2FscyBiZWxvdyBz dWdnZXN0IHRvIHVzZSwgYW1vbmcgb3RoZXIgdGhpbmdzLCB0aGUgc2Vzc2lvbiBrZXk8YnI+DQph czxicj4NCiZndDsgaW5wdXQgdG8gdGhhdCBmdW5jdGlvbi4gVGhhdCBzb3VuZHMgcHJldHR5IHN0 cmFpZ2h0IGZvcndhcmQgYnV0IHJhaXNlcyB0aGU8YnI+DQomZ3Q7IHF1ZXN0aW9uIHdoeSB3ZSBm YWlsIHRvIHRydXN0IHRoZSBpbXBsZW1lbnRlciB0byBjcmVhdGUgcmFuZG9tIGtleSBpZHMgYnV0 PGJyPg0KJmd0OyB0aGVuIHN0aWxsIHRydXN0IHRoZW0gdG8gY3JlYXRlIHJhbmRvbSBrZXlzLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0J3MgZmluZSBmb3IgbWUgbmV2ZXJ0aGVsZXNzLjxicj4N CiZndDsgPGJyPg0KJmd0OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXM8YnI+DQomZ3Q7IDxicj4NCiZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IEppbSBTY2hhYWQg W21haWx0bzo8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+XTxicj4NCiZndDsgU2VudDogMjQgSnVu ZSAyMDE4IDEwOjE1PGJyPg0KJmd0OyBUbzogJ0JlbmphbWluIEthZHVrJzsgJ01pa2UgSm9uZXMn PGJyPg0KJmd0OyBDYzogSGFubmVzIFRzY2hvZmVuaWc7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1p ZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb25AaWV0Zi5vcmc8L2E+Ozxi cj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmFjZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFj ZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJFOiBbQWNlXSBLZXkgSURzIC4uLiBS RTogV0dMQyBvbiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtPGJyPg0KJmd0OyBwb3NzZXNz aW9uLTAyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaW5raW5nIHRoaW5ncyB0aHJvdWdoLCBJIHdv dWxkIGJlIG1vcmUgY29tZm9ydGFibGUgd2l0aCBzb21ldGhpbmcgbGlrZTxicj4NCiZndDsgdGhl PGJyPg0KJmd0OyBmb2xsb3dpbmc6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEuJm5ic3A7IENyZWF0 ZSBhIGNvbmZpcm1hdGlvbiBjYWxsZWQgJ2NvbXB1dGVkIGtleSBpZCcuJm5ic3A7IFRoaXMgaGFz IHR3byBiYXNpYzxicj4NCiZndDsgdmFsdWVzOiZuYnNwOyBXaGF0IGlzIHRoZSBjb21wdXRhdGlv biBtZXRob2Q/Jm5ic3A7IFdoYXQgaXMgdGhlIHByb29mIHZhbHVlPyZuYnNwOyBZb3U8YnI+DQpj YW48YnI+DQomZ3Q7IG9wdGlvbmFsbHkgaGF2ZSBhbiB1bnByb3RlY3RlZCBLSUQgdmFsdWUgdXNl ZCB0byBmaWx0ZXIgdGhlIHNldCBvZiBrZXlzIG9uPGJyPg0KdGhlPGJyPg0KJmd0OyBSUyBkb3du IHRvIGEgcmVhc29uYWJsZSBzZXQgdG8gZW51bWVyYXRlIChob3BlZnVsbHkgb25lKS48YnI+DQom Z3Q7IDxicj4NCiZndDsgMi4mbmJzcDsgRm9yIFJQSyBhbmQgVExTOiZuYnNwOyBEZWZpbmUgYSBt ZXRob2QgY2FsbGVkIGhhc2ggb2YgU1BLSSB3aGljaCBoYXMgYSBoYXNoPGJyPg0KJmd0OyBtZXRo b2QgYXMgYSBwYXJhbWV0ZXIuJm5ic3A7IEdpdmVuIHRoYXQgdGhpcyBjYW4gYmUgY29tcHV0ZWQg aW5kZXBlbmRlbnRseSBieTxicj4NCiZndDsgYWxsIGVudGl0aWVzIGJhc2VkIG9uIGEgUHVibGlj IEtleSB2YWx1ZSBhbmQgaXQgd2lsbCBiZSB1bmlxdWUgdGhlbiB5b3U8YnI+DQpoYXZlIGE8YnI+ DQomZ3Q7IGtleSBpZGVudGlmaWVyIHRoYXQgd2lsbCBub3QgaGF2ZSBjb2xsaXNpb25zIGluZGVw ZW5kZW50IG9mIHdobyBpc3N1ZXMgdGhlPGJyPg0KJmd0OyBDV1QuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDMuJm5ic3A7IEZvciBQU0sgYW5kIFRMUzombmJzcDsgRGVmaW5lIGEgbWV0aG9kIHdoaWNo IHRha2VzIHNvbWUgcGFyYW1ldGVyczxicj4NCmluY2x1ZGluZzxicj4NCiZndDsgdGhlIGtleSB2 YWx1ZSwgdGhlIENXVCBpc3N1ZXIgaWRlbnRpdHkgYW5kIHBlcmhhcHMgc29tZSByYW5kb20gc3Ry aW5nIGFuZDxicj4NCiZndDsgY29tcHV0ZSBhIHByb29mIG9mIHBvc3Nlc3Npb24gdmFsdWUgb24g dGhlIFBTSy48YnI+DQomZ3Q7IDxicj4NCiZndDsgNC4mbmJzcDsgRm9yIFBTSyBhbmQgT1NDT1JF OiBEZWZpbmUgYSBzaW1pbGFyIG1ldGhvZCB0aGUgcXVlc3Rpb24gd291bGQgYmUgd2hhdDxicj4N CiZndDsgdGhlIGtleSB2YWx1ZSBpcyB0byBiZSB1c2VkIGJ1dCB0aGF0IGNhbiBiZSBkZWZpbmVk IGFzIHBhcnQgb2YgT1NDT1JFPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoZW4gdXNpbmcgdGhlIGtl eXMgZm9yIFRMUzxicj4NCiZndDsgPGJyPg0KJmd0OyBGb3IgUlBLIHRoZSBrZXkgaXMgY2Fycmll ZCBpbiB0aGUgaGFuZHNoYWtlIGFuZCB0aGUgc2VydmVyL2NsaWVudCBjYW48YnI+DQomZ3Q7IGdl bmVyYXRlIHRoZSBjb21wdXRlZCBrZXkgaWQgYW5kIGNvbXBhcmUgaXQgdG8gd2hhdCB0aGUgQVMg ZGlzdHJpYnV0ZWQuPGJyPg0KJmd0OyBUaGUgc2VydmVyIGNhbiBpZGVudGlmeSB3aGljaCBDV1Rz IGFyZSBhcHBsaWNhYmxlIGJ5IGVpdGhlciBjb21wYXJpc29uIG9mPGJyPg0KJmd0OyB0aGUgUlBL cyBvciB0aGUgY29tcHV0ZWQga2V5IGlkLiZuYnNwOyBUaGlzIG1lYW5zIHlvdSBoYXZlIGEgaGln aCBwcm9iYWJpbGl0eTxicj4NCiZndDsgdGhhdCB5b3Ugd2lsbCBub3QgbWFrZSBhIG1pc3Rha2Ug YW5kIG1hdGNoIHRvIHRoZSB3cm9uZyBrZXkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZvciBQU0sg dGhlIGlkZW50aWZpZXIgaXMgY2FycmllZCBpbiB0aGUgaGFuZHNoYWtlIHdoaWNoIGlzIHVzZWQg dG8gbG9vazxicj4NCnVwIGE8YnI+DQomZ3Q7IGtleSB2YWx1ZSBhbmQgdGhlIGhhbmRzaGFrZSBp cyBwZXJmb3JtZWQuJm5ic3A7IEJ5IG1hdGNoaW5nIGNvbXB1dGVkIGtleSBpZHM8YnI+DQomZ3Q7 IHdpdGggdGhlIHNlY3JldCB2YWx1ZSBvbmUgY2FuIGVuc3VyZSB0byBhIGhpZ2ggcHJvYmFibHkg dGhhdCBvbmx5IENXVHM8YnI+DQp0aGF0PGJyPg0KJmd0OyByZWZlcmVuY2UgdGhlIHNhbWUgc2Vj cmV0IGFyZSBnb2luZyB0byBiZSB1c2VkIGZvciBwZXJtaXNzaW9ucyBldmVuIGlmPGJyPg0KdGhl eTxicj4NCiZndDsgY29tZSBmcm9tIGRpZmZlcmVudCBBUyBlbnRpdGllcy48YnI+DQomZ3Q7IDxi cj4NCiZndDsgRm9yIE9TQ09SRSBpdCBpcyBzaW1pbGFyLCB0aGUgaWRlbnRpZmllciBpcyB1c2Vk IHRvIGxvb2sgdXAgYSBrZXkgdmFsdWU8YnI+DQphbmQgYnk8YnI+DQomZ3Q7IGRlY3J5cHRpbmcg dGhlIENXVCB0aGUga2V5IHZhbHVlIGlzIHByb29mZWQuJm5ic3A7IFlvdSB0aGVuIG1hdGNoIGNv bXB1dGVkIGtleTxicj4NCiZndDsgaWRzIGluIHRoZSBzYW1lIG1hbm5lci48YnI+DQomZ3Q7IDxi cj4NCiZndDsgSWYgeW91IHJlYWxseSB3YW50IHRvIGhhdmUgc29tZXRoaW5nIHRoYXQgaXMgbm90 IGNyeXB0b2dyYXBoaWNhbGx5PGJyPg0KY29tcHV0ZWQ8YnI+DQomZ3Q7IGFuZCBwb2ludCB0byBz b21ldGhpbmcgZWxzZSwgdGhlbiBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIG1lIHRvIHJlZmVyZW5j ZSBhPGJyPg0KJmd0OyBDV1QgaXNzdWVkIGJ5IHRoZSBzYW1lIGVudGl0eSBhbmQgc2F5ICZxdW90 O3VzZSB0aGUgc2FtZSBjb25mb3JtYXRpb24gbWV0aG9kPGJyPg0KJmd0OyBhcyB0aGlzIENXVCBk b2VzJnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBqaW08YnI+DQomZ3Q7IDxicj4NCiZndDsg Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBCZW5q YW1pbiBLYWR1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthZHVrQG1pdC5lZHUiIHRhcmdldD0iX2Js YW5rIj5rYWR1a0BtaXQuZWR1PC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgU2VudDogU2F0dXJkYXks IEp1bmUgMjMsIDIwMTggMTE6MzAgUE08YnI+DQomZ3Q7ICZndDsgVG86IE1pa2UgSm9uZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2Js YW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBD YzogSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5p Z0Bhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4m Z3Q7OyBKaW0gU2NoYWFkPGJyPg0KJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBh dWd1c3RjZWxsYXJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYXVndXN0Y2VsbGFycy5jb208 L2E+Jmd0Ozs8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1p ZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbkBpZXRmLm9yZzwvYT47PGJyPg0KJmd0OyAm Z3Q7IDxhIGhyZWY9Im1haWx0bzphY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hY2VAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbQWNlXSBLZXkgSURzIC4uLiBS RTogV0dMQyBvbjxicj4NCiZndDsgJmd0OyBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtPGJy Pg0KJmd0OyAmZ3Q7IHBvc3Nlc3Npb24tMDI8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg T24gRnJpLCBKdW4gMjIsIDIwMTggYXQgMDg6NDg6MzVQTSAmIzQzOzAwMDAsIE1pa2UgSm9uZXMg d3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU2VlIG15IG5vdGUganVzdCBub3cgcHJvcG9zaW5n IHRoaXMgdGV4dCB0byBKaW06PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmcXVvdDtMaWtld2lzZSwgaWYgUG9QIGtleXMgYXJlIHVzZWQgZm9yIG11bHRpcGxlIGRpZmZl cmVudCBraW5kcyBvZiBDV1RzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW48YnI+DQomZ3Q7IGFuPGJy Pg0KJmd0OyAmZ3Q7IGFwcGxpY2F0aW9uIGFuZCB0aGUgUG9QIGtleXMgYXJlIGlkZW50aWZpZWQg YnkgS2V5IElEcywgY2FyZSBtdXN0IGJlPGJyPg0KJmd0OyAmZ3Q7IHRha2VuPGJyPg0KJmd0OyB0 bzxicj4NCiZndDsgJmd0OyBrZWVwIHRoZSBrZXlzIGZvciB0aGUgZGlmZmVyZW50IGtpbmRzIG9m IENXVHMgc2VncmVnYXRlZCBzbyB0aGF0IGFuPGJyPg0KJmd0OyBhdHRhY2tlcjxicj4NCiZndDsg Jmd0OyBjYW5ub3QgY2F1c2UgdGhlIHdyb25nIFBvUCBrZXkgdG8gYmUgdXNlZCBieSB1c2luZyBh IHZhbGlkIEtleSBJRCBmb3I8YnI+DQomZ3Q7ICZndDsgdGhlIHdyb25nIGtpbmQgb2YgQ1dULiZx dW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXMgbG9uZyBhcyB0 aGUgUG9QIGtleXMgZm9yIGRpZmZlcmVudCBjb250ZXh0cyBhcmUga2VwdCBzZWdyZWdhdGVkLDxi cj4NCiZndDsgJmd0OyAmZ3Q7IEtleTxicj4NCiZndDsgSUQ8YnI+DQomZ3Q7ICZndDsgY29sbGlz aW9ucyBvciByZXVzZSBjYXVzZSBubyBwcm9ibGVtcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgSWYgd2UgdHJ1c3QgZXZlcnlvbmUgdG8gaW1wbGVtZW50IHRoaW5ncyBwcm9wZXJseS4m bmJzcDsgV2Ugc2hvdWxkIHByb2JhYmx5PGJyPg0KJmd0OyBvbmx5PGJyPg0KJmd0OyAmZ3Q7IHRh a2UgdGhhdCByaXNrIGlmIHdlIGdldCBzb21lIG90aGVyIGJlbmVmaXQgZnJvbSBpdCwgdGhvdWdo LiZuYnNwOyBKaW08YnI+DQomZ3Q7IG1lbnRpb25lZDxicj4NCiZndDsgJmd0OyAob2ZmLWxpc3Q/ KSBhIHNjZW5hcmlvIGludm9sdmluZyBnaXZpbmcgdGhlIHNhbWUgY2xpZW50IGFkZGl0aW9uYWw8 YnI+DQomZ3Q7IHByaXZpbGVnZXMsIGFuZDxicj4NCiZndDsgJmd0OyBvZiBjb3Vyc2Ugd2UgY2Fu IGdhaW4gc29tZSBzaW1wbGljaXR5IHNhdmluZ3MgaWYgd2UgZG9uJ3QgbmVlZCB0bzxicj4NCiZn dDsgJmd0OyBlbmZvcmNlIGdsb2JhbCBrZXktaWQgdW5pcXVlbmVzcyAoZm9yIGFwcHJvcHJpYXRl IHZhbHVlcyBvZiAmcXVvdDtnbG9iYWwmcXVvdDspLjxicj4NCiZndDsgJmd0OyBTbyB0aGlzPGJy Pg0KJmd0OyBtYXk8YnI+DQomZ3Q7ICZndDsgd2VsbCBiZSB0aGUgcmlnaHQgdGhpbmcgdG8gZG87 IEkganVzdCBkb24ndCB0aGluayBpdCdzIHdpdGhvdXQ8YnI+DQomZ3Q7ICZndDsgdHJhZGVvZmZz PGJyPg0KJmd0OyBhcyB5b3VyPGJyPg0KJmd0OyAmZ3Q7IHRleHQgc2VlbXMgdG8gaW1wbHkuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC1CZW48YnI+DQomZ3Q7IDxicj4NCiZndDsgSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmU8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50LDxicj4NCiZndDsg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIHRvPGJyPg0KYW55PGJyPg0KJmd0OyBvdGhlciBwZXJzb24sIHVzZSBpdCBm b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluPGJyPg0K YW55PGJyPg0KJmd0OyBtZWRpdW0uIFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2Yg dGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBh bHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3Nl IHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl LA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5r IHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR0801MB2112509D0220E8DA6A8AEDC2FA480VI1PR0801MB2112_-- From nobody Wed Jun 27 00:59:05 2018 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 9D645130E87; Wed, 27 Jun 2018 00:59:03 -0700 (PDT) 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 r0_fXAThNZBI; Wed, 27 Jun 2018 00:59:02 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEA31277D2; Wed, 27 Jun 2018 00:59:01 -0700 (PDT) Received: from Jude (128.93.88.230) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 27 Jun 2018 00:55:29 -0700 From: Jim Schaad To: 'Hannes Tschofenig' , 'Benjamin Kaduk' , 'Mike Jones' CC: , References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> In-Reply-To: Date: Wed, 27 Jun 2018 09:58:29 +0200 Message-ID: <013c01d40dec$a4c6c540$ee544fc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQHH3wOzAp0N2z4AwuijgAIaIIxmAaqrEKcBY2dBsQIhpQR+ousoYRA= X-Originating-IP: [128.93.88.230] Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 27 Jun 2018 07:59:04 -0000 I agree that some F2F on this would be useful. > -----Original Message----- > From: Hannes Tschofenig > Sent: Wednesday, June 27, 2018 9:32 AM > To: Jim Schaad ; 'Benjamin Kaduk' > ; 'Mike Jones' > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > Hi Jim, > > It sounds like we need some high bandwidth face-to-face time on this issue > in Montreal. > This is an interesting issue and IMHO reaches outside the CWT PoP > document. > > Ciao > Hannes > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: 26 June 2018 18:57 > To: Hannes Tschofenig; 'Benjamin Kaduk'; 'Mike Jones' > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > Hannes, > > My worry is not about implementers getting this correct and picking random > key ids. My worry is about an attacker seeing the key id of somebody and > trying to use it either with the same or a different AS and getting a key and > then getting permissions associated with the initial key that they should not > be doing. > > This is about an attack not about getting things to generally work right. > > Jim > > > > -----Original Message----- > > From: Hannes Tschofenig > > Sent: Tuesday, June 26, 2018 6:09 PM > > To: Jim Schaad ; 'Benjamin Kaduk' > > ; 'Mike Jones' > > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > > Subject: RE: [Ace] Key IDs ... RE: WGLC on > > draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Hi Jim, > > > > you are essentially proposing that we should not directly use the key > > id > that > > is in the CWT-PoP but rather use it as input in a key derivation function. > The > > details of that key derivation function are specified outside the > > CWT-POP document and most likely in the context of the various profiles. > > Your proposals below suggest to use, among other things, the session > > key > as > > input to that function. That sounds pretty straight forward but raises > > the question why we fail to trust the implementer to create random key > > ids but then still trust them to create random keys. > > > > That's fine for me nevertheless. > > > > Ciao > > Hannes > > > > -----Original Message----- > > From: Jim Schaad [mailto:ietf@augustcellars.com] > > Sent: 24 June 2018 10:15 > > To: 'Benjamin Kaduk'; 'Mike Jones' > > Cc: Hannes Tschofenig; > > draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > ace@ietf.org > > Subject: RE: [Ace] Key IDs ... RE: WGLC on > > draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Thinking things through, I would be more comfortable with something > > like the > > following: > > > > 1. Create a confirmation called 'computed key id'. This has two > > basic > > values: What is the computation method? What is the proof value? > > You > can > > optionally have an unprotected KID value used to filter the set of > > keys on > the > > RS down to a reasonable set to enumerate (hopefully one). > > > > 2. For RPK and TLS: Define a method called hash of SPKI which has a > > hash method as a parameter. Given that this can be computed > > independently by all entities based on a Public Key value and it will > > be unique then you > have a > > key identifier that will not have collisions independent of who issues > > the CWT. > > > > 3. For PSK and TLS: Define a method which takes some parameters > including > > the key value, the CWT issuer identity and perhaps some random string > > and compute a proof of possession value on the PSK. > > > > 4. For PSK and OSCORE: Define a similar method the question would be > > what the key value is to be used but that can be defined as part of > > OSCORE > > > > When using the keys for TLS > > > > For RPK the key is carried in the handshake and the server/client can > > generate the computed key id and compare it to what the AS distributed. > > The server can identify which CWTs are applicable by either comparison > > of the RPKs or the computed key id. This means you have a high > > probability that you will not make a mistake and match to the wrong key. > > > > For PSK the identifier is carried in the handshake which is used to > > look > up a > > key value and the handshake is performed. By matching computed key > > ids with the secret value one can ensure to a high probably that only > > CWTs > that > > reference the same secret are going to be used for permissions even if > they > > come from different AS entities. > > > > For OSCORE it is similar, the identifier is used to look up a key > > value > and by > > decrypting the CWT the key value is proofed. You then match computed > > key ids in the same manner. > > > > If you really want to have something that is not cryptographically > computed > > and point to something else, then it makes more sense to me to > > reference a CWT issued by the same entity and say "use the same > > conformation method as this CWT does". > > > > jim > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Saturday, June 23, 2018 11:30 PM > > > To: Mike Jones > > > Cc: Hannes Tschofenig ; Jim Schaad > > > ; > > > draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > > ace@ietf.org > > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > > draft-ietf-ace-cwt-proof-of- > > > possession-02 > > > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > > See my note just now proposing this text to Jim: > > > > > > > > "Likewise, if PoP keys are used for multiple different kinds of > > > > CWTs in > > an > > > application and the PoP keys are identified by Key IDs, care must be > > > taken > > to > > > keep the keys for the different kinds of CWTs segregated so that an > > attacker > > > cannot cause the wrong PoP key to be used by using a valid Key ID > > > for the wrong kind of CWT." > > > > > > > > As long as the PoP keys for different contexts are kept > > > > segregated, Key > > ID > > > collisions or reuse cause no problems. > > > > > > If we trust everyone to implement things properly. We should > > > probably > > only > > > take that risk if we get some other benefit from it, though. Jim > > mentioned > > > (off-list?) a scenario involving giving the same client additional > > privileges, and > > > of course we can gain some simplicity savings if we don't need to > > > enforce global key-id uniqueness (for appropriate values of "global"). > > > So this > > may > > > well be the right thing to do; I just don't think it's without > > > tradeoffs > > as your > > > text seems to imply. > > > > > > -Ben > > > > 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. > > 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. From nobody Thu Jun 28 08:40:01 2018 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 62292130DC7 for ; Thu, 28 Jun 2018 08:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, 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 tkTPa3cejm19 for ; Thu, 28 Jun 2018 08:39:54 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 212D8130FFB for ; Thu, 28 Jun 2018 08:39:54 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id b10-v6so2633034pgq.11 for ; Thu, 28 Jun 2018 08:39:54 -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=X52jTUtMmaa0Kqr21lsh0kVmDJjErhryaA2A9UGiAV4=; b=g3b+GlLWeEYVahn9UtjWPaJi6rl5H+yIgXtgHDfbhRqjWYg+W7BBFhTpD/D7rOfpxA k3Bha/ur6DTiweyOEfSn3Fz/gHIPHAWbnez/c3LFCZrqTy/4fdlgqBCQ7FsiUy6UgrU8 764ujIyYhW2+8PxrKWckz/5IY5Po35oJuSD+6nyZjJPjcLf87nKsbPEZzeaCzMVQxLGt nDE2xavXVal6YCKeEqbmSx5YoGCvMwX6Dvkn7iFOY9+faRxwETSRtqEjWqJDvnIdugub MR8IiY4rR7kKIpGXYPbXmmwz07pVsHNUUyzhXlZEQ1qcvHObvfN7UkmiJZXdy1zEDcHg icfg== 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=X52jTUtMmaa0Kqr21lsh0kVmDJjErhryaA2A9UGiAV4=; b=ko55zHPpsm4nRDJuRK2F8aOgoy/UIdXeNEUFn2a9nfHMDboUQ4wrlKA3rG5ELkIGkt x7gtYAFrINYM9Xqg8BJbTikXfep21GNVBNQTa1yYTpv4XJ3WSSZPxSq1sZ5fhctVHb/k 2l6I0fUwpkzIsm+9yZ52WKcHYJx89SP1NdLc3PHf6AZa+gizG/MxyRegSFPxM9AJWmdc bkSIWXIV5GdjczsjnHbOneEQLiKhZPynIo/SSQWupxp0Q3F947kImk32NDSAR+X5OlCG zr+SoJ0fokQYw8/vRBP9YZPSLPjChJoOgQPBcVla66SyLXFaaOghlZglpaAKgqMOqFGq 6CCw== X-Gm-Message-State: APt69E1RVjN48NOOk1589jYSyIBjzWd4X2PnrtCL7unI10gJ5TPAkH4l +AQqjt9LoIjchIQdCRYYJBQBaMCkNIY3o2yUkq/iwQ== X-Google-Smtp-Source: ADUXVKIRBST3oo330z0fAot10EHenJnAKiyPvF7+TQKGDAp5M5+/IvDqgOnevwbEN3+n0tGCdeYMQjO3211sx3ViIU4= X-Received: by 2002:a65:608c:: with SMTP id t12-v6mr9500080pgu.159.1530200393383; Thu, 28 Jun 2018 08:39:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:b28c:0:0:0:0 with HTTP; Thu, 28 Jun 2018 08:39:52 -0700 (PDT) In-Reply-To: <013301d40de7$39660220$ac320660$@augustcellars.com> References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> <013301d40de7$39660220$ac320660$@augustcellars.com> From: Samuel Erdtman Date: Thu, 28 Jun 2018 17:39:52 +0200 Message-ID: To: Jim Schaad Cc: Samuel Erdtman , draft-ietf-ace-cwt-proof-of-possession@ietf.org, Mike Jones , Hannes Tschofenig , Benjamin Kaduk , ace Content-Type: multipart/alternative; boundary="000000000000e21725056fb58a33" Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 28 Jun 2018 15:39:59 -0000 --000000000000e21725056fb58a33 Content-Type: text/plain; charset="UTF-8" Thanks for the clarifying comments here comes a few replies since I will not be able to join the IETF meeting :-( see inline On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad wrote: > > > > > *From:* Samuel Erdtman > *Sent:* Wednesday, June 27, 2018 8:18 AM > *To:* Jim Schaad > *Cc:* Hannes Tschofenig ; Benjamin Kaduk < > kaduk@mit.edu>; Mike Jones ; > draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > > > Jim, are you saying that if the client can pick the key identifier and if > it has seen a key identifier of another client it could request a PoP token > with the observed key-id and the observed subject but with an new key. > I guess this is a potential scenario that could be worth mentioning in > security considerations. > > [JLS] No I am not assuming that the observed subject is also chosen by the > attacker, just the observed key-id. > OK, see comments below on why I think the attacker would have to know the subject too. > > If we look at ACE-OAuth there are as far as I can tell a few things that > makes this a hard attack to do. > > When the client makes the token request it is authenticated. > > [JLS] Unclear why this is relevant. I am asking for this new token as > myself. > In my opinion authentication of the client will significantly lessen the number of attackers since they need to have some initial access. i.e. no absolute protection but one layer. > And with the subject being the authenticated client cannot control what > goes into the cwt as subject > > [JLS] You are making an assumption that a) the subject is actually going > to be populated rather than be left empty and thus be anonymous and 2) that > the resource server is going to make any enforcement based on the subject. > I expect it to be done based on audience and scope only. > My assumption is that RS will uniquely identify the key with Issuer, Subject and Key-ID. If subject is omitted for an anonymous token I assume that the AS (Issuer) makes sure the key-id is unique during the lifetime of the token. If issuer is left out I assume it is identified by the CWT signing key or that the RS only accept tokens from one AS. When the key is found and has been used to authenticate the user of the token I too expect that the RS does the authorization based on audience and scope. > > Since the cwt with the PoP key is signed there is no way for the attacking > client to retro-fit the token to suit its needs e.g. change subject or > key-id. > > [JLS] I am asking for a new token not trying to modify an existing token > so this is not especially relevant. > Based on my previous statement you should not be able to impersonate the observed key with a token issued for you. > > Finally I think it is preferable if the server selects key identifier. > > [JLS] I would agree, however if you have two AS that are operating in the > same authorization range and are not tightly linked then this is not easy > for doing an additional privilege token where the POP is identified by the > KID. This is even harder if an RS is going to allow two different AS from > different scopes to be authoritative as they would never coordinate > together. > In the case of RS accepting tokens from multiple ASs I think the RS must use the issuer (in the CWT) to do key lookup. > > > Best regards > //Samuel > > > On Tue, 26 Jun 2018 at 18:57, Jim Schaad wrote: > > Hannes, > > My worry is not about implementers getting this correct and picking random > key ids. My worry is about an attacker seeing the key id of somebody and > trying to use it either with the same or a different AS and getting a key > and then getting permissions associated with the initial key that they > should not be doing. > > This is about an attack not about getting things to generally work right. > > Jim > > > > -----Original Message----- > > From: Hannes Tschofenig > > Sent: Tuesday, June 26, 2018 6:09 PM > > To: Jim Schaad ; 'Benjamin Kaduk' > > ; 'Mike Jones' > > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Hi Jim, > > > > you are essentially proposing that we should not directly use the key id > that > > is in the CWT-PoP but rather use it as input in a key derivation > function. > The > > details of that key derivation function are specified outside the CWT-POP > > document and most likely in the context of the various profiles. > > Your proposals below suggest to use, among other things, the session key > as > > input to that function. That sounds pretty straight forward but raises > the > > question why we fail to trust the implementer to create random key ids > but > > then still trust them to create random keys. > > > > That's fine for me nevertheless. > > > > Ciao > > Hannes > > > > -----Original Message----- > > From: Jim Schaad [mailto:ietf@augustcellars.com] > > Sent: 24 June 2018 10:15 > > To: 'Benjamin Kaduk'; 'Mike Jones' > > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > ace@ietf.org > > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Thinking things through, I would be more comfortable with something like > > the > > following: > > > > 1. Create a confirmation called 'computed key id'. This has two basic > > values: What is the computation method? What is the proof value? You > can > > optionally have an unprotected KID value used to filter the set of keys > on > the > > RS down to a reasonable set to enumerate (hopefully one). > > > > 2. For RPK and TLS: Define a method called hash of SPKI which has a > hash > > method as a parameter. Given that this can be computed independently by > > all entities based on a Public Key value and it will be unique then you > have a > > key identifier that will not have collisions independent of who issues > the > > CWT. > > > > 3. For PSK and TLS: Define a method which takes some parameters > including > > the key value, the CWT issuer identity and perhaps some random string and > > compute a proof of possession value on the PSK. > > > > 4. For PSK and OSCORE: Define a similar method the question would be > what > > the key value is to be used but that can be defined as part of OSCORE > > > > When using the keys for TLS > > > > For RPK the key is carried in the handshake and the server/client can > > generate the computed key id and compare it to what the AS distributed. > > The server can identify which CWTs are applicable by either comparison of > > the RPKs or the computed key id. This means you have a high probability > > that you will not make a mistake and match to the wrong key. > > > > For PSK the identifier is carried in the handshake which is used to look > up a > > key value and the handshake is performed. By matching computed key ids > > with the secret value one can ensure to a high probably that only CWTs > that > > reference the same secret are going to be used for permissions even if > they > > come from different AS entities. > > > > For OSCORE it is similar, the identifier is used to look up a key value > and by > > decrypting the CWT the key value is proofed. You then match computed key > > ids in the same manner. > > > > If you really want to have something that is not cryptographically > computed > > and point to something else, then it makes more sense to me to reference > a > > CWT issued by the same entity and say "use the same conformation method > > as this CWT does". > > > > jim > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Saturday, June 23, 2018 11:30 PM > > > To: Mike Jones > > > Cc: Hannes Tschofenig ; Jim Schaad > > > ; > > > draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > > ace@ietf.org > > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > > draft-ietf-ace-cwt-proof-of- > > > possession-02 > > > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > > See my note just now proposing this text to Jim: > > > > > > > > "Likewise, if PoP keys are used for multiple different kinds of CWTs > > > > in > > an > > > application and the PoP keys are identified by Key IDs, care must be > > > taken > > to > > > keep the keys for the different kinds of CWTs segregated so that an > > attacker > > > cannot cause the wrong PoP key to be used by using a valid Key ID for > > > the wrong kind of CWT." > > > > > > > > As long as the PoP keys for different contexts are kept segregated, > > > > Key > > ID > > > collisions or reuse cause no problems. > > > > > > If we trust everyone to implement things properly. We should probably > > only > > > take that risk if we get some other benefit from it, though. Jim > > mentioned > > > (off-list?) a scenario involving giving the same client additional > > privileges, and > > > of course we can gain some simplicity savings if we don't need to > > > enforce global key-id uniqueness (for appropriate values of "global"). > > > So this > > may > > > well be the right thing to do; I just don't think it's without > > > tradeoffs > > as your > > > text seems to imply. > > > > > > -Ben > > > > 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 > > --000000000000e21725056fb58a33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the clarifying comments here comes a few r= eplies since I will not be able to join the IETF meeting :-(

=
see inline

On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad <ietf@augus= tcellars.com> wrote:

=C2=A0

=C2=A0

From: Samuel Erdtman <erdtman@spotify.com>
Sent: Wednesda= y, June 27, 2018 8:18 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Benjamin Kaduk <kaduk@mit.edu>; Mik= e Jones <Michael.Jones@microsoft.com>; draft-ietf-ace-cwt-proof-o= f-possession@ietf.org; ace@ietf.org
Subject: Re: [Ace] Key I= Ds ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02=

=C2=A0

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Jim, are you saying th= at if the client can pick the key identifier and if it has seen a key ident= ifier of another client it could request a PoP token with the observed key-= id and the observed subject but with an new key.
I gue= ss this is a potential scenario that could be worth mentioning in security = considerations.

[JLS] No I am not assuming that the observed subject is = also chosen by the attacker, just the observed key-id.
=

OK, see comments below on wh= y I think the attacker would have to know the subject too.
= =C2=A0
=


= If we look at ACE-OAuth there are as far as I can tell a few things that ma= kes this a hard attack to do.

When the client makes the token reques= t it is authenticated.

[JLS] Unclear why this is relevant.=C2=A0 I am as= king for this new token as myself.

In my opinion authentication of the client will = significantly lessen the number of attackers since they need to have some i= nitial access. i.e. no absolute protection but one layer.


And= with the subject being the authenticated client cannot control what goes i= nto the cwt as subject

[JLS] You are making an assumption that a) the su= bject is actually going to be populated rather than be left empty and thus = be anonymous and 2) that the resource server is going to make any enforceme= nt based on the subject.=C2=A0 I expect it to be done based on audience and= scope only.

=
My assumption is that RS will uniquely identify the key with Issuer, S= ubject and Key-ID. If subject is omitted for an anonymous token I assume th= at the AS (Issuer) makes sure the key-id is unique during the lifetime of t= he token. If issuer is left out I assume it is identified by the CWT signin= g key or that the RS only accept tokens from one AS.
When the= key is found and has been used to authenticate the user of the token I too= expect that the RS does the authorization based on audience and scope.
=
=C2=A0


Since the cwt with the PoP key is signed there is no way for the= attacking client to retro-fit the token to suit its needs e.g. change subj= ect or key-id.

[JLS] I am asking for a new token not trying to modify an= existing token so this is not especially relevant.

Based on my previous statement you should not be able to im= personate the observed key with a token issued for you.


Finally I think it is pr= eferable if the server selects key identifier.

[JLS] I would agree, how= ever if you have two AS that are operating in the same authorization range = and are not tightly linked then this is not easy for doing an additional pr= ivilege token where the POP is identified by the KID.=C2=A0 This is even ha= rder if an RS is going to allow two different AS from different scopes to b= e authoritative as they would never coordinate together.

In the case of RS accepting tokens from multiple ASs I= think the RS must use the issuer (in the CWT) to do key lookup.
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">



Best regards
//Samuel
<= br>

= On Tue, 26 Jun 2018 at 18:57, Jim Schaad <ietf@augustcellars.com> wrote:<= u>

=

Hann= es,

My worry is not about implementers getting this correct and pick= ing random
key ids.=C2=A0 My worry is about an attacker seeing the key i= d of somebody and
trying to use it either with the same or a different A= S and getting a key
and then getting permissions associated with the ini= tial key that they
should not be doing.

This is about an attack n= ot about getting things to generally work right.

Jim


>= -----Original Message-----
> From: Hannes Tschofenig <Hannes.Tschofenig@arm.c= om>
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Sch= aad <ietf@au= gustcellars.com>; 'Benjamin Kaduk'
> <kaduk@mit.edu>; 'Mike Jone= s' <Michael.Jones@microsoft.com>
> Cc: draft-ietf-ace-c= wt-proof-of-possession@ietf.org; ace@ietf.org

>= Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of-> possession-02
>
> Hi Jim,
>
> you are esse= ntially proposing that we should not directly use the key id
that
>= ; is in the CWT-PoP but rather use it as input in a key derivation function= .
The
> details of that key derivation function are specified outs= ide the CWT-POP
> document and most likely in the context of the vari= ous profiles.
> Your proposals below suggest to use, among other thin= gs, the session key
as
> input to that function. That sounds prett= y straight forward but raises the
> question why we fail to trust the= implementer to create random key ids but
> then still trust them to = create random keys.
>
> That's fine for me nevertheless.>
> Ciao
> Hannes
>
> -----Original Message-= ----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: 24 Ju= ne 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'> Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-pos= session@ietf.org;
> ace@ietf.org
> Subject: R= E: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> poss= ession-02
>
> Thinking things through, I would be more comfort= able with something like
> the
> following:
>
> 1.= =C2=A0 Create a confirmation called 'computed key id'.=C2=A0 This h= as two basic
> values:=C2=A0 What is the computation method?=C2=A0 Wh= at is the proof value?=C2=A0 You
can
> optionally have an unprotec= ted KID value used to filter the set of keys on
the
> RS down to a= reasonable set to enumerate (hopefully one).
>
> 2.=C2=A0 For= RPK and TLS:=C2=A0 Define a method called hash of SPKI which has a hash> method as a parameter.=C2=A0 Given that this can be computed independ= ently by
> all entities based on a Public Key value and it will be un= ique then you
have a
> key identifier that will not have collision= s independent of who issues the
> CWT.
>
> 3.=C2=A0 For = PSK and TLS:=C2=A0 Define a method which takes some parameters
including=
> the key value, the CWT issuer identity and perhaps some random str= ing and
> compute a proof of possession value on the PSK.
> > 4.=C2=A0 For PSK and OSCORE: Define a similar method the question wou= ld be what
> the key value is to be used but that can be defined as p= art of OSCORE
>
> When using the keys for TLS
>
>= For RPK the key is carried in the handshake and the server/client can
&= gt; generate the computed key id and compare it to what the AS distributed.=
> The server can identify which C= WTs are applicable by either comparison of
> the RPKs or the computed= key id.=C2=A0 This means you have a high probability
> that you will= not make a mistake and match to the wrong key.
>
> For PSK th= e identifier is carried in the handshake which is used to look
up a
&= gt; key value and the handshake is performed.=C2=A0 By matching computed ke= y ids
> with the secret value one can ensure to a high probably that = only CWTs
that
> reference the same secret are going to be used fo= r permissions even if
they
> come from different AS entities.
&= gt;
> For OSCORE it is similar, the identifier is used to look up a = key value
and by
> decrypting the CWT the key value is proofed.=C2= =A0 You then match computed key
> ids in the same manner.
> > If you really want to have something that is not cryptographicallycomputed
> and point to something else, then it makes more sense to = me to reference a
> CWT issued by the same entity and say "use t= he same conformation method
> as this CWT does".
>
>= ; jim
>
> > -----Original Message-----
> > From: B= enjamin Kaduk <kaduk@= mit.edu>
> > Sent: Saturday, June 23, 2018 11:30 PM
>= > To: Mike Jones <Michael.Jones@microsoft.com>
> > Cc: Hannes = Tschofenig <Hannes.Tschofenig@arm.com>; Jim Schaad
> > <ietf@augustcellars.com= >;
> > draft-ietf-ace-cwt-proof-of-possessio= n@ietf.org;
> > ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE: WGLC o= n
> > draft-ietf-ace-cwt-proof-of-
> > possession-02
&= gt; >
> > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones = wrote:
> > > See my note just now proposing this text to Jim:> > >
> > > "Likewise, if PoP keys are used for= multiple different kinds of CWTs
> > > in
> an
> &= gt; application and the PoP keys are identified by Key IDs, care must be> > taken
> to
> > keep the keys for the different ki= nds of CWTs segregated so that an
> attacker
> > cannot caus= e the wrong PoP key to be used by using a valid Key ID for
> > the= wrong kind of CWT."
> > >
> > > As long as th= e PoP keys for different contexts are kept segregated,
> > > Ke= y
> ID
> > collisions or reuse cause no problems.
> &g= t;
> > If we trust everyone to implement things properly.=C2=A0 We= should probably
> only
> > take that risk if we get some ot= her benefit from it, though.=C2=A0 Jim
> mentioned
> > (off-= list?) a scenario involving giving the same client additional
> privi= leges, and
> > of course we can gain some simplicity savings if we= don't need to
> > enforce global key-id uniqueness (for appro= priate values of "global").
> > So this
> may
&= gt; > well be the right thing to do; I just don't think it's wit= hout
> > tradeoffs
> as your
> > text seems to impl= y.
> >
> > -Ben
>
> IMPORTANT NOTICE: The co= ntents of this email and any attachments are
> confidential and may a= lso 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 informati= on in
any
> medium. Thank you.


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


--000000000000e21725056fb58a33-- From nobody Thu Jun 28 22:57:39 2018 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 83F12130E36; Thu, 28 Jun 2018 22:57:37 -0700 (PDT) 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, 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 0jl2E-AQTjkA; Thu, 28 Jun 2018 22:57:34 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3391A129C6A; Thu, 28 Jun 2018 22:57:33 -0700 (PDT) Received: from Jude (213.174.99.145) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 28 Jun 2018 22:54:00 -0700 From: Jim Schaad To: 'Samuel Erdtman' CC: 'Samuel Erdtman' , , 'Mike Jones' , 'Hannes Tschofenig' , 'Benjamin Kaduk' , 'ace' References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> <013301d40de7$39660220$ac320660$@augustcellars.com> In-Reply-To: Date: Fri, 29 Jun 2018 07:57:00 +0200 Message-ID: <027e01d40f6e$01e326b0$05a97410$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027F_01D40F7E.C56DF280" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJmkbQj82tMYvZUbCUZIMhlVFE4oQHH3wOzAp0N2z4AwuijgAIaIIxmAaqrEKcBY2dBsQHPZ3YMAaTEJ9wBbSlX/qLXY+sw X-Originating-IP: [213.174.99.145] Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 05:57:38 -0000 ------=_NextPart_000_027F_01D40F7E.C56DF280 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Samuel Erdtman =20 Sent: Thursday, June 28, 2018 5:40 PM To: Jim Schaad Cc: Samuel Erdtman ; = draft-ietf-ace-cwt-proof-of-possession@ietf.org; Mike Jones = ; Hannes Tschofenig = ; Benjamin Kaduk ; ace = Subject: Re: [Ace] Key IDs ... RE: WGLC on = draft-ietf-ace-cwt-proof-of-possession-02 =20 Thanks for the clarifying comments here comes a few replies since I will = not be able to join the IETF meeting :-( =20 see inline =20 On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad > wrote: =20 =20 From: Samuel Erdtman > = Sent: Wednesday, June 27, 2018 8:18 AM To: Jim Schaad > Cc: Hannes Tschofenig >; Benjamin Kaduk >; Mike Jones >; = draft-ietf-ace-cwt-proof-of-possession@ietf.org = ; ace@ietf.org = =20 Subject: Re: [Ace] Key IDs ... RE: WGLC on = draft-ietf-ace-cwt-proof-of-possession-02 =20 Jim, are you saying that if the client can pick the key identifier and = if it has seen a key identifier of another client it could request a PoP = token with the observed key-id and the observed subject but with an new = key.=20 I guess this is a potential scenario that could be worth mentioning in = security considerations. [JLS] No I am not assuming that the observed subject is also chosen by = the attacker, just the observed key-id. OK, see comments below on why I think the attacker would have to know = the subject too. =20 If we look at ACE-OAuth there are as far as I can tell a few things that = makes this a hard attack to do. When the client makes the token request it is authenticated. [JLS] Unclear why this is relevant. I am asking for this new token as = myself. In my opinion authentication of the client will significantly lessen the = number of attackers since they need to have some initial access. i.e. no = absolute protection but one layer. =20 [JLS] I am already in the system and have full credentials. I am trying = to get the same permissions that you have. Not all attackers are = external to the system. =20 And with the subject being the authenticated client cannot control what = goes into the cwt as subject [JLS] You are making an assumption that a) the subject is actually going = to be populated rather than be left empty and thus be anonymous and 2) = that the resource server is going to make any enforcement based on the = subject. I expect it to be done based on audience and scope only. My assumption is that RS will uniquely identify the key with Issuer, = Subject and Key-ID. If subject is omitted for an anonymous token I = assume that the AS (Issuer) makes sure the key-id is unique during the = lifetime of the token. If issuer is left out I assume it is identified = by the CWT signing key or that the RS only accept tokens from one AS. When the key is found and has been used to authenticate the user of the = token I too expect that the RS does the authorization based on audience = and scope. =20 [JLS] I am not sure how this is going to work. As the CS I do a DTLS = connect to the RS and put the Key-ID into the PSK identifier field. The = RS now has the Key-ID, but does not have the Issuer or Subject = information. Are you using this triple value binding someplace else? =20 Since the cwt with the PoP key is signed there is no way for the = attacking client to retro-fit the token to suit its needs e.g. change = subject or key-id. [JLS] I am asking for a new token not trying to modify an existing token = so this is not especially relevant. Based on my previous statement you should not be able to impersonate the = observed key with a token issued for you. =20 [JLS] Given two anonymous subject fields, the subject would not be a = differentiator Finally I think it is preferable if the server selects key identifier.=20 [JLS] I would agree, however if you have two AS that are operating in = the same authorization range and are not tightly linked then this is not = easy for doing an additional privilege token where the POP is identified = by the KID. This is even harder if an RS is going to allow two = different AS from different scopes to be authoritative as they would = never coordinate together. In the case of RS accepting tokens from multiple ASs I think the RS must = use the issuer (in the CWT) to do key lookup. =20 [JLS] That may be true, however I have still not seen how to do the = processing of getting a supplementary CWT and thus don=E2=80=99t know = how it works. I was assuming that the Client would send a KID as part = of it=E2=80=99s request to the AS so one now has interesting questions = of how the server does the assignment. Also having a KID as part of an = asymmetric key is probably going to be normal operating procedure so = this is another case where the Client is providing one. =20 Jim =20 Best regards //Samuel On Tue, 26 Jun 2018 at 18:57, Jim Schaad > wrote: Hannes, My worry is not about implementers getting this correct and picking = random key ids. My worry is about an attacker seeing the key id of somebody = and trying to use it either with the same or a different AS and getting a = key and then getting permissions associated with the initial key that they should not be doing. This is about an attack not about getting things to generally work = right. Jim > -----Original Message----- > From: Hannes Tschofenig > > Sent: Tuesday, June 26, 2018 6:09 PM > To: Jim Schaad = >; 'Benjamin Kaduk' > >; 'Mike Jones' = > > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org = ; ace@ietf.org = =20 > Subject: RE: [Ace] Key IDs .... RE: WGLC on = draft-ietf-ace-cwt-proof-of- > possession-02 >=20 > Hi Jim, >=20 > you are essentially proposing that we should not directly use the key = id that > is in the CWT-PoP but rather use it as input in a key derivation = function. The > details of that key derivation function are specified outside the = CWT-POP > document and most likely in the context of the various profiles. > Your proposals below suggest to use, among other things, the session = key as > input to that function. That sounds pretty straight forward but raises = the > question why we fail to trust the implementer to create random key ids = but > then still trust them to create random keys. >=20 > That's fine for me nevertheless. >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com = ] > Sent: 24 June 2018 10:15 > To: 'Benjamin Kaduk'; 'Mike Jones' > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org = ; > ace@ietf.org =20 > Subject: RE: [Ace] Key IDs .... RE: WGLC on = draft-ietf-ace-cwt-proof-of- > possession-02 >=20 > Thinking things through, I would be more comfortable with something = like > the > following: >=20 > 1. Create a confirmation called 'computed key id'. This has two = basic > values: What is the computation method? What is the proof value? = You can > optionally have an unprotected KID value used to filter the set of = keys on the > RS down to a reasonable set to enumerate (hopefully one). >=20 > 2. For RPK and TLS: Define a method called hash of SPKI which has a = hash > method as a parameter. Given that this can be computed independently = by > all entities based on a Public Key value and it will be unique then = you have a > key identifier that will not have collisions independent of who issues = the > CWT. >=20 > 3. For PSK and TLS: Define a method which takes some parameters including > the key value, the CWT issuer identity and perhaps some random string = and > compute a proof of possession value on the PSK. >=20 > 4. For PSK and OSCORE: Define a similar method the question would be = what > the key value is to be used but that can be defined as part of OSCORE >=20 > When using the keys for TLS >=20 > For RPK the key is carried in the handshake and the server/client can > generate the computed key id and compare it to what the AS = distributed. > The server can identify which CWTs are applicable by either comparison = of > the RPKs or the computed key id. This means you have a high = probability > that you will not make a mistake and match to the wrong key. >=20 > For PSK the identifier is carried in the handshake which is used to = look up a > key value and the handshake is performed. By matching computed key = ids > with the secret value one can ensure to a high probably that only CWTs that > reference the same secret are going to be used for permissions even if they > come from different AS entities. >=20 > For OSCORE it is similar, the identifier is used to look up a key = value and by > decrypting the CWT the key value is proofed. You then match computed = key > ids in the same manner. >=20 > If you really want to have something that is not cryptographically computed > and point to something else, then it makes more sense to me to = reference a > CWT issued by the same entity and say "use the same conformation = method > as this CWT does". >=20 > jim >=20 > > -----Original Message----- > > From: Benjamin Kaduk > > > Sent: Saturday, June 23, 2018 11:30 PM > > To: Mike Jones > > > Cc: Hannes Tschofenig >; Jim Schaad > > >; > > draft-ietf-ace-cwt-proof-of-possession@ietf.org = ; > > ace@ietf.org =20 > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > See my note just now proposing this text to Jim: > > > > > > "Likewise, if PoP keys are used for multiple different kinds of = CWTs > > > in > an > > application and the PoP keys are identified by Key IDs, care must be > > taken > to > > keep the keys for the different kinds of CWTs segregated so that an > attacker > > cannot cause the wrong PoP key to be used by using a valid Key ID = for > > the wrong kind of CWT." > > > > > > As long as the PoP keys for different contexts are kept = segregated, > > > Key > ID > > collisions or reuse cause no problems. > > > > If we trust everyone to implement things properly. We should = probably > only > > take that risk if we get some other benefit from it, though. Jim > mentioned > > (off-list?) a scenario involving giving the same client additional > privileges, and > > of course we can gain some simplicity savings if we don't need to > > enforce global key-id uniqueness (for appropriate values of = "global"). > > So this > may > > well be the right thing to do; I just don't think it's without > > tradeoffs > as your > > text seems to imply. > > > > -Ben >=20 > 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 =20 https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_027F_01D40F7E.C56DF280 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Samuel Erdtman <samuel@erdtman.se>
Sent: Thursday, June = 28, 2018 5:40 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Samuel Erdtman = <erdtman@spotify.com>; = draft-ietf-ace-cwt-proof-of-possession@ietf.org; Mike Jones = <Michael.Jones@microsoft.com>; Hannes Tschofenig = <Hannes.Tschofenig@arm.com>; Benjamin Kaduk <kaduk@mit.edu>; = ace <ace@ietf.org>
Subject: Re: [Ace] Key IDs ... RE: = WGLC on = draft-ietf-ace-cwt-proof-of-possession-02

 

Thanks for the clarifying comments here comes a few = replies since I will not be able to join the IETF meeting = :-(

 

see inline

 

On Wed, = Jun 27, 2018 at 9:19 AM, Jim Schaad <ietf@augustcellars.com> = wrote:

 <= /o:p>

 <= /o:p>

From:= Samuel Erdtman <erdtman@spotify.com>
Sent: = Wednesday, June 27, 2018 8:18 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Hannes = Tschofenig <Hannes.Tschofenig@arm.com>; Benjamin Kaduk = <kaduk@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>; draft-ietf-ace-cwt-proof-of-possession@ietf.org; = ace@ietf.org
Subject: Re: [Ace] Key IDs = ... RE: WGLC on = draft-ietf-ace-cwt-proof-of-possession-02

 <= /o:p>

Jim, are you = saying that if the client can pick the key identifier and if it has seen = a key identifier of another client it could request a PoP token with the = observed key-id and the observed subject but with an new key.
I = guess this is a potential scenario that could be worth mentioning in = security considerations.

[JLS] No I am not = assuming that the observed subject is also chosen by the attacker, just = the observed = key-id.

OK, see comments below on why I think the attacker = would have to know the subject too.

 


If we look at = ACE-OAuth there are as far as I can tell a few things that makes this a = hard attack to do.

When the client makes the token request it is = authenticated.

[JLS] Unclear why = this is relevant.  I am asking for this new token as = myself.

In my opinion authentication of the client will = significantly lessen the number of attackers since they need to have = some initial access. i.e. no absolute protection but one = layer.

 

[JLS] I am already in the system and have full = credentials.=C2=A0 I am trying to get the same permissions that you = have.=C2=A0 Not all attackers are external to the = system.

 


And with the = subject being the authenticated client cannot control what goes into the = cwt as subject

[JLS] You are = making an assumption that a) the subject is actually going to be = populated rather than be left empty and thus be anonymous and 2) that = the resource server is going to make any enforcement based on the = subject.  I expect it to be done based on audience and scope = only.

My assumption is that RS will uniquely identify the = key with Issuer, Subject and Key-ID. If subject is omitted for an = anonymous token I assume that the AS (Issuer) makes sure the key-id is = unique during the lifetime of the token. If issuer is left out I assume = it is identified by the CWT signing key or that the RS only accept = tokens from one AS.

When = the key is found and has been used to authenticate the user of the token = I too expect that the RS does the authorization based on audience and = scope.

 

[JLS] I am not sure how this is going to work.=C2=A0 = As the CS I do a DTLS connect to the RS and put the Key-ID into the PSK = identifier field.=C2=A0 The RS now has the Key-ID, but does not have the = Issuer or Subject information.=C2=A0 Are you using this triple value = binding someplace else?

 


Since the cwt = with the PoP key is signed there is no way for the attacking client to = retro-fit the token to suit its needs e.g. change subject or = key-id.

[JLS] I am asking = for a new token not trying to modify an existing token so this is not = especially = relevant.

Based on my previous statement you should not be able = to impersonate the observed key with a token issued for = you.

 

[JLS] Given two anonymous subject fields, the subject = would not be a differentiator

=


Finally I = think it is preferable if the server selects key identifier. =

[JLS] I would = agree, however if you have two AS that are operating in the same = authorization range and are not tightly linked then this is not easy for = doing an additional privilege token where the POP is identified by the = KID.  This is even harder if an RS is going to allow two different = AS from different scopes to be authoritative as they would never = coordinate = together.

In the case of RS accepting tokens from multiple ASs I = think the RS must use the issuer (in the CWT) to do key = lookup.

 

[JLS] That may be true, however I have still not seen = how to do the processing of getting a supplementary CWT and thus = don=E2=80=99t know how it works.=C2=A0 I was assuming that the Client = would send a KID as part of it=E2=80=99s request to the AS so one now = has interesting questions of how the server does the assignment.=C2=A0 = Also having a KID as part of an asymmetric key is probably going to be = normal operating procedure so this is another case where the Client is = providing one.

 

Jim

 



Best = regards
//Samuel

On Tue, 26 = Jun 2018 at 18:57, Jim Schaad <ietf@augustcellars.com> = wrote:

Hannes,

My = worry is not about implementers getting this correct and picking = random
key ids.  My worry is about an attacker seeing the key id = of somebody and
trying to use it either with the same or a different = AS and getting a key
and then getting permissions associated with the = initial key that they
should not be doing.

This is about an = attack not about getting things to generally work = right.

Jim


> -----Original Message-----
> = From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> Sent: = Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad <ietf@augustcellars.com>; 'Benjamin = Kaduk'
> <kaduk@mit.edu>; 'Mike Jones' <Michael.Jones@microsoft.com>
> Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; = ace@ietf.org

> Subject: RE: [Ace] Key IDs .... RE: WGLC on = draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Hi = Jim,
>
> you are essentially proposing that we should not = directly use the key id
that
> is in the CWT-PoP but rather use = it as input in a key derivation function.
The
> details of that = key derivation function are specified outside the CWT-POP
> = document and most likely in the context of the various profiles.
> = Your proposals below suggest to use, among other things, the session = key
as
> input to that function. That sounds pretty straight = forward but raises the
> question why we fail to trust the = implementer to create random key ids but
> then still trust them = to create random keys.
>
> That's fine for me = nevertheless.
>
> Ciao
> Hannes
>
> = -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: 24 June 2018 = 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes = Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org;> ace@ietf.org

> Subject: RE: [Ace] Key IDs .... RE: WGLC on = draft-ietf-ace-cwt-proof-of-
> possession-02
>
> = Thinking things through, I would be more comfortable with something = like
> the
> following:
>
> 1.  Create a = confirmation called 'computed key id'.  This has two basic
> = values:  What is the computation method?  What is the proof = value?  You
can
> optionally have an unprotected KID value = used to filter the set of keys on
the
> RS down to a reasonable = set to enumerate (hopefully one).
>
> 2.  For RPK and = TLS:  Define a method called hash of SPKI which has a hash
> = method as a parameter.  Given that this can be computed = independently by
> all entities based on a Public Key value and it = will be unique then you
have a
> key identifier that will not = have collisions independent of who issues the
> CWT.
> =
> 3.  For PSK and TLS:  Define a method which takes = some parameters
including
> the key value, the CWT issuer = identity and perhaps some random string and
> compute a proof of = possession value on the PSK.
>
> 4.  For PSK and = OSCORE: Define a similar method the question would be what
> the = key value is to be used but that can be defined as part of = OSCORE
>
> When using the keys for TLS
>
> For = RPK the key is carried in the handshake and the server/client = can
> generate the computed key id and compare it to what the AS = distributed.

> The server can identify which CWTs are applicable = by either comparison of
> the RPKs or the computed key id.  = This means you have a high probability
> that you will not make a = mistake and match to the wrong key.
>
> For PSK the = identifier is carried in the handshake which is used to look
up = a
> key value and the handshake is performed.  By matching = computed key ids
> with the secret value one can ensure to a high = probably that only CWTs
that
> reference the same secret are = going to be used for permissions even if
they
> come from = different AS entities.
>
> For OSCORE it is similar, the = identifier is used to look up a key value
and by
> decrypting = the CWT the key value is proofed.  You then match computed = key
> ids in the same manner.
>
> If you really want = to have something that is not cryptographically
computed
> and = point to something else, then it makes more sense to me to reference = a
> CWT issued by the same entity and say "use the same = conformation method
> as this CWT does".
>
> = jim
>
> > -----Original Message-----
> > From: = Benjamin Kaduk <kaduk@mit.edu>
> > Sent: Saturday, = June 23, 2018 11:30 PM
> > To: Mike Jones <Michael.Jones@microsoft.com>
> > Cc: = Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Jim Schaad
> = > <ietf@augustcellars.com>;
> > draft-ietf-ace-cwt-proof-of-possession@ietf.org;> > ace@ietf.org
> > Subject: Re: [Ace] Key = IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-
> = > possession-02
> >
> > On Fri, Jun 22, 2018 at = 08:48:35PM +0000, Mike Jones wrote:
> > > See my note just = now proposing this text to Jim:
> > >
> > > = "Likewise, if PoP keys are used for multiple different kinds of = CWTs
> > > in
> an
> > application and the = PoP keys are identified by Key IDs, care must be
> > = taken
> to
> > keep the keys for the different kinds of = CWTs segregated so that an
> attacker
> > cannot cause = the wrong PoP key to be used by using a valid Key ID for
> > = the wrong kind of CWT."
> > >
> > > As long = as the PoP keys for different contexts are kept segregated,
> > = > Key
> ID
> > collisions or reuse cause no = problems.
> >
> > If we trust everyone to implement = things properly.  We should probably
> only
> > take = that risk if we get some other benefit from it, though.  = Jim
> mentioned
> > (off-list?) a scenario involving = giving the same client additional
> privileges, and
> > = of course we can gain some simplicity savings if we don't need = to
> > enforce global key-id uniqueness (for appropriate values = of "global").
> > So this
> may
> > = well be the right thing to do; I just don't think it's without
> = > tradeoffs
> as your
> > text seems to imply.
> = >
> > -Ben
>
> 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

 

------=_NextPart_000_027F_01D40F7E.C56DF280-- From nobody Thu Jun 28 23:10:10 2018 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 4E177130DC4 for ; Thu, 28 Jun 2018 23:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 vgaq1yNfMYfQ for ; Thu, 28 Jun 2018 23:10:01 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 659F7130E36 for ; Thu, 28 Jun 2018 23:10:01 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id u16-v6so3727224pfh.3 for ; Thu, 28 Jun 2018 23:10:01 -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=D9f5yuW5q8+FlPInZHJ4xWVhujmekujcUMoLgBZzLq0=; b=peedWGkVMwkPZEESWaoOe8/UE1aOK4ZO1ajpeapae9ywnqeVvXhp9d4RbJm+7X3Qkq O1rhtDsMyL6TvN1NtFUIp4o+3CVXB/K50AqhnCFQsp6BpVpy4HNDoUqZwOIyKvO3+7G4 9KABOHMqIO3DxhpGlJgcEN0MSw1IKln54G8sgr8lEEDx4P5Z8+pyMkEAk7rXfZY1M/VM NHUeM6iO0Ea/22NrKM7oSpZJZZRZZP2WAVRnLR3NOc+cttSQ8O4JV6Ks4S3ij+Qu12jI CiTmQto5F7sAG2Kf8LwfPAxKcwziCPtwjMoYI9DWqNBYKVG0iy18HZxcG6Ut7A8VshP1 mGOg== 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=D9f5yuW5q8+FlPInZHJ4xWVhujmekujcUMoLgBZzLq0=; b=pByGr4ALC2NIL+K6UBKe9G2HYXbWG1zAkJ4wjfBiurSxIB/qvFCWcgVFt38f8JS0On /ELe4pL1x2nRSIpI3dP16iv7D7C5wgv84H7IFJ53qDNHrBN4G9W3iOmtKZrTkoZvJ0R2 MbfBZWUdwX4xocwcmA7PUgVmukcT5lJEL5MtteFrCkDGyOWmMp0SEU+PftQeUbwVdafg ySWpR9kqm25VFy1HwVMSvHH/VqbY42wrmR3GXxhubGdBcl+Fwn0+2yszuVLneBDPJAlW 7BqsQNK3yOJiiHun6C3YGUXnelTnuk9Y37w9W586pyRQSIUkXVkRBiGeYRavA1+6aK6p rjwQ== X-Gm-Message-State: APt69E0bfF2H0MlT3ZliozxIfuu31RzrfYr7tP3cRVVglnigQyNfpi2e EaevWhRQWk5KCwpOSdVCCoHHyYhG0TTPDM3k+JvSbA== X-Google-Smtp-Source: ADUXVKIF3RjsfvRbUFm1FXwi1JigHQxe8OBIYOZCFVmH80y6i8OwpdcZzqJiUD+5HuKFAHYztoCeKkk08ZYQvpH8RNA= X-Received: by 2002:a65:594b:: with SMTP id g11-v6mr11667497pgu.260.1530252600634; Thu, 28 Jun 2018 23:10:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:d598:0:0:0:0 with HTTP; Thu, 28 Jun 2018 23:09:59 -0700 (PDT) In-Reply-To: <027e01d40f6e$01e326b0$05a97410$@augustcellars.com> References: <20180622204344.GP64617@kduck.kaduk.org> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> <013301d40de7$39660220$ac320660$@augustcellars.com> <027e01d40f6e$01e326b0$05a97410$@augustcellars.com> From: Samuel Erdtman Date: Fri, 29 Jun 2018 08:09:59 +0200 Message-ID: To: Jim Schaad Cc: Samuel Erdtman , draft-ietf-ace-cwt-proof-of-possession@ietf.org, Mike Jones , Hannes Tschofenig , Benjamin Kaduk , ace Content-Type: multipart/alternative; boundary="000000000000ad8305056fc1b2d6" Archived-At: Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 06:10:07 -0000 --000000000000ad8305056fc1b2d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable see inline On Fri, Jun 29, 2018 at 7:57 AM, Jim Schaad wrote: > > > > > *From:* Samuel Erdtman > *Sent:* Thursday, June 28, 2018 5:40 PM > *To:* Jim Schaad > *Cc:* Samuel Erdtman ; draft-ietf-ace-cwt-proof-of- > possession@ietf.org; Mike Jones ; Hannes > Tschofenig ; Benjamin Kaduk ; > ace > *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > > > Thanks for the clarifying comments here comes a few replies since I will > not be able to join the IETF meeting :-( > > > > see inline > > > > On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad > wrote: > > > > > > *From:* Samuel Erdtman > *Sent:* Wednesday, June 27, 2018 8:18 AM > *To:* Jim Schaad > *Cc:* Hannes Tschofenig ; Benjamin Kaduk < > kaduk@mit.edu>; Mike Jones ; > draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > > > Jim, are you saying that if the client can pick the key identifier and if > it has seen a key identifier of another client it could request a PoP tok= en > with the observed key-id and the observed subject but with an new key. > I guess this is a potential scenario that could be worth mentioning in > security considerations. > > [JLS] No I am not assuming that the observed subject is also chosen by th= e > attacker, just the observed key-id. > > OK, see comments below on why I think the attacker would have to know the > subject too. > > > > > If we look at ACE-OAuth there are as far as I can tell a few things that > makes this a hard attack to do. > > When the client makes the token request it is authenticated. > > [JLS] Unclear why this is relevant. I am asking for this new token as > myself. > > In my opinion authentication of the client will significantly lessen the > number of attackers since they need to have some initial access. i.e. no > absolute protection but one layer. > > > > [JLS] I am already in the system and have full credentials. I am trying > to get the same permissions that you have. Not all attackers are externa= l > to the system. > I agree, but the number of such attackers are fewer and you could revoke access to such users. It is not perfect but it is better than nothing. > > > > And with the subject being the authenticated client cannot control what > goes into the cwt as subject > > [JLS] You are making an assumption that a) the subject is actually going > to be populated rather than be left empty and thus be anonymous and 2) th= at > the resource server is going to make any enforcement based on the subject= . > I expect it to be done based on audience and scope only. > > My assumption is that RS will uniquely identify the key with Issuer, > Subject and Key-ID. If subject is omitted for an anonymous token I assume > that the AS (Issuer) makes sure the key-id is unique during the lifetime = of > the token. If issuer is left out I assume it is identified by the CWT > signing key or that the RS only accept tokens from one AS. > > When the key is found and has been used to authenticate the user of the > token I too expect that the RS does the authorization based on audience a= nd > scope. > > > > [JLS] I am not sure how this is going to work. As the CS I do a DTLS > connect to the RS and put the Key-ID into the PSK identifier field. The = RS > now has the Key-ID, but does not have the Issuer or Subject information. > Are you using this triple value binding someplace else? > I would not send the key-id in the PSK identifier I would send the full token as described in draft-ietf-ace-dtls-authorize (4.1. DTLS Channel Setup Between C and RS). > > > > Since the cwt with the PoP key is signed there is no way for the attackin= g > client to retro-fit the token to suit its needs e.g. change subject or > key-id. > > [JLS] I am asking for a new token not trying to modify an existing token > so this is not especially relevant. > > Based on my previous statement you should not be able to impersonate the > observed key with a token issued for you. > > > > [JLS] Given two anonymous subject fields, the subject would not be a > differentiator > I agree so the AS (issuer) MUST keep key-id unique for the lifetime of the token. > > Finally I think it is preferable if the server selects key identifier. > > [JLS] I would agree, however if you have two AS that are operating in the > same authorization range and are not tightly linked then this is not easy > for doing an additional privilege token where the POP is identified by th= e > KID. This is even harder if an RS is going to allow two different AS fro= m > different scopes to be authoritative as they would never coordinate > together. > > In the case of RS accepting tokens from multiple ASs I think the RS must > use the issuer (in the CWT) to do key lookup. > > > > [JLS] That may be true, however I have still not seen how to do the > processing of getting a supplementary CWT and thus don=E2=80=99t know how= it > works. I was assuming that the Client would send a KID as part of it=E2= =80=99s > request to the AS so one now has interesting questions of how the server > does the assignment. Also having a KID as part of an asymmetric key is > probably going to be normal operating procedure so this is another case > where the Client is providing one. > > > > Jim > > > > > > Best regards > //Samuel > > On Tue, 26 Jun 2018 at 18:57, Jim Schaad wrote: > > Hannes, > > My worry is not about implementers getting this correct and picking rando= m > key ids. My worry is about an attacker seeing the key id of somebody and > trying to use it either with the same or a different AS and getting a key > and then getting permissions associated with the initial key that they > should not be doing. > > This is about an attack not about getting things to generally work right. > > Jim > > > > -----Original Message----- > > From: Hannes Tschofenig > > Sent: Tuesday, June 26, 2018 6:09 PM > > To: Jim Schaad ; 'Benjamin Kaduk' > > ; 'Mike Jones' > > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > > > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of= - > > possession-02 > > > > Hi Jim, > > > > you are essentially proposing that we should not directly use the key i= d > that > > is in the CWT-PoP but rather use it as input in a key derivation > function. > The > > details of that key derivation function are specified outside the CWT-P= OP > > document and most likely in the context of the various profiles. > > Your proposals below suggest to use, among other things, the session ke= y > as > > input to that function. That sounds pretty straight forward but raises > the > > question why we fail to trust the implementer to create random key ids > but > > then still trust them to create random keys. > > > > That's fine for me nevertheless. > > > > Ciao > > Hannes > > > > -----Original Message----- > > From: Jim Schaad [mailto:ietf@augustcellars.com] > > Sent: 24 June 2018 10:15 > > To: 'Benjamin Kaduk'; 'Mike Jones' > > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > ace@ietf.org > > > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of= - > > possession-02 > > > > Thinking things through, I would be more comfortable with something lik= e > > the > > following: > > > > 1. Create a confirmation called 'computed key id'. This has two basic > > values: What is the computation method? What is the proof value? You > can > > optionally have an unprotected KID value used to filter the set of keys > on > the > > RS down to a reasonable set to enumerate (hopefully one). > > > > 2. For RPK and TLS: Define a method called hash of SPKI which has a > hash > > method as a parameter. Given that this can be computed independently b= y > > all entities based on a Public Key value and it will be unique then you > have a > > key identifier that will not have collisions independent of who issues > the > > CWT. > > > > 3. For PSK and TLS: Define a method which takes some parameters > including > > the key value, the CWT issuer identity and perhaps some random string a= nd > > compute a proof of possession value on the PSK. > > > > 4. For PSK and OSCORE: Define a similar method the question would be > what > > the key value is to be used but that can be defined as part of OSCORE > > > > When using the keys for TLS > > > > For RPK the key is carried in the handshake and the server/client can > > generate the computed key id and compare it to what the AS distributed. > > > The server can identify which CWTs are applicable by either comparison = of > > the RPKs or the computed key id. This means you have a high probabilit= y > > that you will not make a mistake and match to the wrong key. > > > > For PSK the identifier is carried in the handshake which is used to loo= k > up a > > key value and the handshake is performed. By matching computed key ids > > with the secret value one can ensure to a high probably that only CWTs > that > > reference the same secret are going to be used for permissions even if > they > > come from different AS entities. > > > > For OSCORE it is similar, the identifier is used to look up a key value > and by > > decrypting the CWT the key value is proofed. You then match computed k= ey > > ids in the same manner. > > > > If you really want to have something that is not cryptographically > computed > > and point to something else, then it makes more sense to me to referenc= e > a > > CWT issued by the same entity and say "use the same conformation method > > as this CWT does". > > > > jim > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Saturday, June 23, 2018 11:30 PM > > > To: Mike Jones > > > Cc: Hannes Tschofenig ; Jim Schaad > > > ; > > > draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > > ace@ietf.org > > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > > draft-ietf-ace-cwt-proof-of- > > > possession-02 > > > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > > See my note just now proposing this text to Jim: > > > > > > > > "Likewise, if PoP keys are used for multiple different kinds of CWT= s > > > > in > > an > > > application and the PoP keys are identified by Key IDs, care must be > > > taken > > to > > > keep the keys for the different kinds of CWTs segregated so that an > > attacker > > > cannot cause the wrong PoP key to be used by using a valid Key ID for > > > the wrong kind of CWT." > > > > > > > > As long as the PoP keys for different contexts are kept segregated, > > > > Key > > ID > > > collisions or reuse cause no problems. > > > > > > If we trust everyone to implement things properly. We should probabl= y > > only > > > take that risk if we get some other benefit from it, though. Jim > > mentioned > > > (off-list?) a scenario involving giving the same client additional > > privileges, and > > > of course we can gain some simplicity savings if we don't need to > > > enforce global key-id uniqueness (for appropriate values of "global")= . > > > So this > > may > > > well be the right thing to do; I just don't think it's without > > > tradeoffs > > as your > > > text seems to imply. > > > > > > -Ben > > > > 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 t= o > 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 > > > --000000000000ad8305056fc1b2d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
see inline

On Fri, Jun 29, 2018 at 7:57 AM, Jim Schaad <ietf@augus= tcellars.com> wrote:

=C2=A0

=C2=A0

From: Samuel Erdtman <samuel@erdtman.se>
Sent: Thursday, June= 28, 2018 5:40 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Samuel Erdtman <erdtman@spotify.com>; draft-ietf-ace-cwt-proof-of-= possession@ietf.org; Mike Jones <Michael.Jones@microsoft.com>; Hannes T= schofenig <Hannes.Tschofenig@arm.com>; Benjamin Kaduk <kaduk@mit.edu>; ace <ace@ietf.org>
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-= cwt-proof-of-possession-02

=C2=A0

Thanks for the clarifying comments here comes a few re= plies since I will not be able to join the IETF meeting :-(

=C2=A0

see inline

=C2=A0

On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad <ietf@augustcellars.com&= gt; wrote:

=C2=A0<= /u>

=C2=A0

<= div>

From: Samuel Erdtman <erdtman@spotify.com>
<= b>Sent: Wednesday, June 27, 2018 8:18 AM
To: Jim Schaad <<= a href=3D"mailto:ietf@augustcellars.com" target=3D"_blank">ietf@augustcella= rs.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; B= enjamin Kaduk <kaduk@= mit.edu>; Mike Jones <Michael.Jones@microsoft.com>; draft-= ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
Subject: Re: [Ace] Ke= y IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02=

=C2=A0

Jim, are you saying that if = the client can pick the key identifier and if it has seen a key identifier = of another client it could request a PoP token with the observed key-id and= the observed subject but with an new key.
I guess this is a potential = scenario that could be worth mentioning in security considerations.<= u>

[JLS] No I am= not assuming that the observed subject is also chosen by the attacker, jus= t the observed key-id.

OK, see comments below on why I think the attacker = would have to know the subject too.

=C2=A0


If we look at ACE-OAuth t= here are as far as I can tell a few things that makes this a hard attack to= do.

When the client makes the token request it is authenticated.=

[JLS] Un= clear why this is relevant.=C2=A0 I am asking for this new token as myself.=

In my opinion authentication of the client = will significantly lessen the number of attackers since they need to have s= ome initial access. i.e. no absolute protection but one layer.

=C2=A0

[JLS] I am already in the system and have full credentials.=C2=A0 I = am trying to get the same permissions that you have.=C2=A0 Not all attacker= s are external to the system.


I agree, but the number of s= uch attackers are fewer and you could revoke access to such users. It is no= t perfect but it is better than nothing.
=C2=A0

=C2=A0


And with the subject = being the authenticated client cannot control what goes into the cwt as sub= ject

[= JLS] You are making an assumption that a) the subject is actually going to = be populated rather than be left empty and thus be anonymous and 2) that th= e resource server is going to make any enforcement based on the subject.=C2= =A0 I expect it to be done based on audience and scope only.<= /p>

My assumption= is that RS will uniquely identify the key with Issuer, Subject and Key-ID.= If subject is omitted for an anonymous token I assume that the AS (Issuer)= makes sure the key-id is unique during the lifetime of the token. If issue= r is left out I assume it is identified by the CWT signing key or that the = RS only accept tokens from one AS.

When the key is found and has been= used to authenticate the user of the token I too expect that the RS does t= he authorization based on audience and scope.

=C2=A0

[JLS] I am= not sure how this is going to work.=C2=A0 As the CS I do a DTLS connect to= the RS and put the Key-ID into the PSK identifier field.=C2=A0 The RS now = has the Key-ID, but does not have the Issuer or Subject information.=C2=A0 = Are you using this triple value binding someplace else?


I would not send= the key-id in the PSK identifier I would send the full token as described = in draft-ietf-ace-dtls-authorize (4.1. DTLS Channel Setup Between C and RS)= .
=C2=A0

=C2=A0=


Since the cwt with the PoP key is signed there= is no way for the attacking client to retro-fit the token to suit its need= s e.g. change subject or key-id.

[JLS] I am asking for a new token not trying to = modify an existing token so this is not especially relevant.<= /p>

Based on my previous statement you should not be able to i= mpersonate the observed key with a token issued for you.

<= p class=3D"MsoNormal">=C2=A0

[JLS] Given two anonymous subject fields, the subject would not be a diffe= rentiator

I agree so the AS (issuer) MUST keep key-id unique for the lif= etime of the token.

<= u>


Finally I think it is preferable if the server selects key id= entifier.

[JLS] I would agree, however if you have two AS that are operating in = the same authorization range and are not tightly linked then this is not ea= sy for doing an additional privilege token where the POP is identified by t= he KID.=C2=A0 This is even harder if an RS is going to allow two different = AS from different scopes to be authoritative as they would never coordinate= together.

In the case of RS accepting token= s from multiple ASs I think the RS must use the issuer (in the CWT) to do k= ey lookup.

=C2=A0

=

[JLS] That may be true, however I have still = not seen how to do the processing of getting a supplementary CWT and thus d= on=E2=80=99t know how it works.=C2=A0 I was assuming that the Client would = send a KID as part of it=E2=80=99s request to the AS so one now has interes= ting questions of how the server does the assignment.=C2=A0 Also having a K= ID as part of an asymmetric key is probably going to be normal operating pr= ocedure so this is another case where the Client is providing one.

=C2=A0

Jim

=C2=A0



Best regards
//Samuel

<= /p>

On Tue, 26 Jun 2018 at 18:57, Jim Schaa= d <ietf@augu= stcellars.com> wrote:

Hannes,

My worry is not about implementers getting t= his correct and picking random
key ids.=C2=A0 My worry is about an attac= ker seeing the key id of somebody and
trying to use it either with the s= ame or a different AS and getting a key
and then getting permissions ass= ociated with the initial key that they
should not be doing.

This = is about an attack not about getting things to generally work right.
Jim


> -----Original Message-----
> From: Hannes Tschof= enig <Han= nes.Tschofenig@arm.com>
> Sent: Tuesday, June 26, 2018 6:09 PM=
> To: Jim Schaad <ietf@augustcellars.com>; 'Benjamin Kaduk'
&g= t; <kaduk@mit.edu= >; 'Mike Jones' <Michael.Jones@microsoft.com>
> Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org

> Subject: RE: [Ace] Key IDs .... RE: WGLC = on draft-ietf-ace-cwt-proof-of-
> possession-02
>
> Hi J= im,
>
> you are essentially proposing that we should not direc= tly use the key id
that
> is in the CWT-PoP but rather use it as i= nput in a key derivation function.
The
> details of that key deriv= ation function are specified outside the CWT-POP
> document and most = likely in the context of the various profiles.
> Your proposals below= suggest to use, among other things, the session key
as
> input to= that function. That sounds pretty straight forward but raises the
> = question why we fail to trust the implementer to create random key ids but<= br>> then still trust them to create random keys.
>
> That&= #39;s fine for me nevertheless.
>
> Ciao
> Hannes
>= ;
> -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.= com]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Ka= duk'; 'Mike Jones'
> Cc: Hannes Tschofenig; dra= ft-ietf-ace-cwt-proof-of-possession@ietf.org;
> ace@ietf.org

> Subject: RE: [Ace] Key IDs .= ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> =
> Thinking things through, I would be more comfortable with somethin= g like
> the
> following:
>
> 1.=C2=A0 Create a co= nfirmation called 'computed key id'.=C2=A0 This has two basic
&g= t; values:=C2=A0 What is the computation method?=C2=A0 What is the proof va= lue?=C2=A0 You
can
> optionally have an unprotected KID value used= to filter the set of keys on
the
> RS down to a reasonable set to= enumerate (hopefully one).
>
> 2.=C2=A0 For RPK and TLS:=C2= =A0 Define a method called hash of SPKI which has a hash
> method as = a parameter.=C2=A0 Given that this can be computed independently by
>= all entities based on a Public Key value and it will be unique then youhave a
> key identifier that will not have collisions independent of= who issues the
> CWT.
>
> 3.=C2=A0 For PSK and TLS:=C2= =A0 Define a method which takes some parameters
including
> the ke= y value, the CWT issuer identity and perhaps some random string and
>= compute a proof of possession value on the PSK.
>
> 4.=C2=A0 = For PSK and OSCORE: Define a similar method the question would be what
&= gt; the key value is to be used but that can be defined as part of OSCORE>
> When using the keys for TLS
>
> For RPK the ke= y is carried in the handshake and the server/client can
> generate th= e computed key id and compare it to what the AS distributed.<= /p>

> The server can identif= y which CWTs are applicable by either comparison of
> the RPKs or the= computed key id.=C2=A0 This means you have a high probability
> that= you will not make a mistake and match to the wrong key.
>
> F= or PSK the identifier is carried in the handshake which is used to look
= up a
> key value and the handshake is performed.=C2=A0 By matching co= mputed key ids
> with the secret value one can ensure to a high proba= bly that only CWTs
that
> reference the same secret are going to b= e used for permissions even if
they
> come from different AS entit= ies.
>
> For OSCORE it is similar, the identifier is used to l= ook up a key value
and by
> decrypting the CWT the key value is pr= oofed.=C2=A0 You then match computed key
> ids in the same manner.>
> If you really want to have something that is not cryptograph= ically
computed
> and point to something else, then it makes more = sense to me to reference a
> CWT issued by the same entity and say &q= uot;use the same conformation method
> as this CWT does".
>= ;
> jim
>
> > -----Original Message-----
> >= ; From: Benjamin Kaduk <kaduk@mit.edu>
> > Sent: Saturday, June 23, 2018 11:30 P= M
> > To: Mike Jones <Michael.Jones@microsoft.com>
> > Cc= : Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Jim Schaad
> > <= ietf@augustcell= ars.com>;
> > draft-ietf-ace-cwt-proof-of-po= ssession@ietf.org;
> > ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE= : WGLC on
> > draft-ietf-ace-cwt-proof-of-
> > possession= -02
> >
> > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mik= e Jones wrote:
> > > See my note just now proposing this text t= o Jim:
> > >
> > > "Likewise, if PoP keys are = used for multiple different kinds of CWTs
> > > in
> an> > application and the PoP keys are identified by Key IDs, care mu= st be
> > taken
> to
> > keep the keys for the diff= erent kinds of CWTs segregated so that an
> attacker
> > can= not cause the wrong PoP key to be used by using a valid Key ID for
> = > the wrong kind of CWT."
> > >
> > > As lo= ng as the PoP keys for different contexts are kept segregated,
> >= > Key
> ID
> > collisions or reuse cause no problems.> >
> > If we trust everyone to implement things properly.= =C2=A0 We should probably
> only
> > take that risk if we ge= t some other benefit from it, though.=C2=A0 Jim
> mentioned
> &= gt; (off-list?) a scenario involving giving the same client additional
&= gt; privileges, and
> > of course we can gain some simplicity savi= ngs if we don't need to
> > enforce global key-id uniqueness (= for appropriate values of "global").
> > So this
>= may
> > well be the right thing to do; I just don't think it&= #39;s without
> > tradeoffs
> as your
> > text seem= s to imply.
> >
> > -Ben
>
> IMPORTANT NOTIC= E: The contents of this email and any attachments are
> confidential = and may also be privileged. If you are not the intended
recipient,
&g= t; 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<= /u>

=C2=A0<= u>


--000000000000ad8305056fc1b2d6-- From nobody Fri Jun 29 02:39:09 2018 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 574F41277D2; Fri, 29 Jun 2018 02:38:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153026513929.30438.18093718639310558504@ietfa.amsl.com> Date: Fri, 29 Jun 2018 02:38:59 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 09:39:00 -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 : OSCORE profile of the Authentication and Authorization for Constrained Environments Framework Authors : Ludwig Seitz Francesca Palombini Martin Gunnarsson Göran Selander Filename : draft-ietf-ace-oscore-profile-02.txt Pages : 18 Date : 2018-06-29 Abstract: This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-02 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-02 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 Fri Jun 29 08:11:05 2018 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 02718130DC0 for ; Fri, 29 Jun 2018 08:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CDlJmAo7mHwi for ; Fri, 29 Jun 2018 08:11:01 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.38]) (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 6ADC9126CC7 for ; Fri, 29 Jun 2018 08:11:01 -0700 (PDT) Received: from 1fYv35-000Pgu-TU by out10d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fYv35-000PhV-Uj for ace@ietf.org; Fri, 29 Jun 2018 08:10:59 -0700 Received: by emcmailer; Fri, 29 Jun 2018 08:10:59 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fYv35-000Pgu-TU for ace@ietf.org; Fri, 29 Jun 2018 08:10:59 -0700 Received: from [10.112.11.36] (10.100.0.158) 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.1466.3; Fri, 29 Jun 2018 17:10:58 +0200 References: <153028452943.30277.11154015427937100128.idtracker@ietfa.amsl.com> To: From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAHNJ01hcmNvIFRpbG9jYSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIb AwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bV ZKqD92JNWDTX6h1MUsgejwj4RXs6UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s8 6ncVygiDUh9fbSDTcuzOp2qgu9nsc8sEsYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK /OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4MxMhmi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST 0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0KnXlAczWxCD3J3XTFK4MES/b3n3oc2GJY8I+ tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZszJeTvsMvc7ATQRUjXkVAQgAlpqfpOi5 GOP3su3gO7pmFXNtoslagBF5ssA2MxI3sGMEXI06x/zcdRKsIyA7lvgQRKDC0WThwoJo6Oh0 ZliLrXGFQrfYnqJLpbZKK/QQaEFT4iPk6edTqdNon5BnKxEDWYu6t35jrYRWcGejSZ1GwNm8 nGimfKApbwwkI+gIxMnQT50u91GhKA7KrBlY2cAoXzjIOTshZvdEI6SMPJtLg1XAsyin8at0 /8+7ckYLnCFHvOBMwbriQREhIyv4RdJ0diw4dUoQ9vRVqxWUjVVQlbtVGGSwGsn/KCihx6TP sIX4xGDuF7A6VeM0NeQPg9eR0Yh0egHX+Dw7TzNQwsIIIwARAQABwsBfBBgBAgAJBQJUjXkV AhsMAAoJEO4mZLQOWNpDxhMH/1jY08t8++Ly5h8nFbBV16EPFtfvOfJkcgHdGvCWM2N8Qewl baiNx8vPeEHMOB+hu/fQNTi/QdRHgPGI92js9DW1Mn+RlvoqLa94fPiiAjmGd+PwUGji83bw zZkaBh5/jXk84Re3knojyoto3sfjVaHYYzlRl8PBIWBpHmS78pxxG6IizOE28j21UfR7HVai hlUw8SkhN52pqN5L7WOrMkRSIlM+VsyX2ALqm7ept08QxG/LAPac2i7oZn5yUXNdh+TVWRGZ hPxJCRU5ZD+MJ2cjkn/69v1XdIh2rgcL+e3KWOhxRTHu67yuLOzBOc3LThJcuQujQrtWWjbX VLqg0jw= X-Forwarded-Message-Id: <153028452943.30277.11154015427937100128.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 29 Jun 2018 17:10:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153028452943.30277.11154015427937100128.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sAZ2cqHFOCNtxdTXyDOwONgNYWeaJeFEa" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: marco.tiloca@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-tiloca-ace-oscoap-joining-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 15:11:04 -0000 --sAZ2cqHFOCNtxdTXyDOwONgNYWeaJeFEa Content-Type: multipart/mixed; boundary="vhsIGRlDy0AeFaLK2nYhw4v0cROIhgz7C"; protected-headers="v1" From: Marco Tiloca To: ace@ietf.org Message-ID: Subject: Fwd: New Version Notification for draft-tiloca-ace-oscoap-joining-04.txt References: <153028452943.30277.11154015427937100128.idtracker@ietfa.amsl.com> In-Reply-To: <153028452943.30277.11154015427937100128.idtracker@ietfa.amsl.com> --vhsIGRlDy0AeFaLK2nYhw4v0cROIhgz7C Content-Type: multipart/alternative; boundary="------------CAB349984F4A77C5FE403DE5" Content-Language: en-US This is a multi-part message in MIME format. --------------CAB349984F4A77C5FE403DE5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, We have just submitted a new version of draft-tiloca-ace-oscoap-joining The updates especially consider the review from Peter van der Stok (thanks!), as well as the latest version of the two drafts: https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm Best, /Marco -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-ace-oscoap-joining-04.txt Date: Fri, 29 Jun 2018 08:02:09 -0700 From: internet-drafts@ietf.org To: Marco Tiloca , Jiye Park = A new version of I-D, draft-tiloca-ace-oscoap-joining-04.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-ace-oscoap-joining Revision: 04 Title: Joining OSCORE groups in ACE Document date: 2018-06-29 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-tiloca-ace-osc= oap-joining-04.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-ace-oscoap-= joining/ Htmlized: https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joini= ng-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-ace-os= coap-joining Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tiloca-ace-osco= ap-joining-04 Abstract: This document describes a method to join a group where communications are based on CoAP and secured with Object Security for Constrained RESTful Environments (OSCORE). The proposed method delegates the authentication and authorization of client nodes that join an OSCORE group through a Group Manager server. This approach builds on the ACE framework for Authentication and Authorization, and leverages protocol-specific profiles of ACE to achieve communication security, proof-of-possession and server authentication. = =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------CAB349984F4A77C5FE403DE5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,

We have just submitted a new version of draft-tiloca-ace-oscoap-joining

The updates especially consider the review from Peter van der Stok (thanks!), as well as the latest version of the two drafts:

https://tools.ietf.org/html/draft-iet= f-core-oscore-groupcomm
https://tools.ietf.org/html/draft-pa= lombini-ace-key-groupcomm

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-ace-oscoap-joining-04.txt
Dat= e: Fri, 29 Jun 2018 08:02:09 -0700
Fro= m: internet-drafts@ietf.org
To:= Marco Tiloca <marco.tiloca@ri.se>, Jiye Park <ji-ye.park@uni-due.de> 


A new version of I-D, draft-tiloca-ace-oscoap-joining-04.txt
has been successfully submitted by Marco Tiloca and posted to the
IETF repository.

Name:		draft-tiloca-ace-oscoap-joining
Revision:	04
Title:		Joining OSCORE groups in ACE
Document date:	2018-06-29
Group:		Individual Submission
Pages:		15
URL:            https://ww=
w.ietf.org/internet-drafts/draft-tiloca-ace-oscoap-joining-04.txt
Status:         https://datatracker.=
ietf.org/doc/draft-tiloca-ace-oscoap-joining/
Htmlized:       https://tools.ietf.org/=
html/draft-tiloca-ace-oscoap-joining-04
Htmlized:       https://datatrac=
ker.ietf.org/doc/html/draft-tiloca-ace-oscoap-joining
Diff:           https://www.iet=
f.org/rfcdiff?url2=3Ddraft-tiloca-ace-oscoap-joining-04

Abstract:
   This document describes a method to join a group where communications
   are based on CoAP and secured with Object Security for Constrained
   RESTful Environments (OSCORE).  The proposed method delegates the
   authentication and authorization of client nodes that join an OSCORE
   group through a Group Manager server.  This approach builds on the
   ACE framework for Authentication and Authorization, and leverages
   protocol-specific profiles of ACE to achieve communication security,
   proof-of-possession and server authentication.

                                                                         =
        =20


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

The IETF Secretariat
--------------CAB349984F4A77C5FE403DE5-- --vhsIGRlDy0AeFaLK2nYhw4v0cROIhgz7C-- --sAZ2cqHFOCNtxdTXyDOwONgNYWeaJeFEa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJbNkv8AAoJEO4mZLQOWNpDzkEH/30Wo0sQZO/m+hkbuSM3CU7Z O+eIOGl9iG2JtX9eIQ/0yMBTH16hi7e/VwsEfgQPAZAxzwMz1FzExoqOFlIT3fD/ 147KqGoQSSOy/XpgN2U0DTXqQwvG0JVJ0h8orm9uPcnH+KOg5tp+0YvV2kcKHvWH x9f9YERysyUMI9F1lg+G/YwwUqpusDAk7iBVPJ0PssJNw2Fx2GnMywW0+lDPrRdN tP1Tmq+Q7w2aVlB7L/gyJZGaWVPzYt37EgYCKXVGBfFy5aA8Khuo8IM8JiCpjCBv Xt55ewh6v8jeBdpjEQwRtF+E23VSSZZQcFy29e5DwRsGEH7ok3NfPSvn0IFpMjA= =8E8B -----END PGP SIGNATURE----- --sAZ2cqHFOCNtxdTXyDOwONgNYWeaJeFEa-- From nobody Fri Jun 29 08:36:20 2018 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 ADA81130E0F for ; Fri, 29 Jun 2018 08:36:12 -0700 (PDT) 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 FmRxl4yXEqrn for ; Fri, 29 Jun 2018 08:36:09 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.40]) (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 57F67130DCA for ; Fri, 29 Jun 2018 08:36:09 -0700 (PDT) Received: from 1fYvRO-000dgf-VB by out10b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fYvRP-000dhT-TF; Fri, 29 Jun 2018 08:36:07 -0700 Received: by emcmailer; Fri, 29 Jun 2018 08:36:07 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fYvRO-000dgf-VB; Fri, 29 Jun 2018 08:36:06 -0700 Received: from [10.112.11.36] (10.100.0.158) 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.1466.3; Fri, 29 Jun 2018 17:36:06 +0200 To: References: <0c356bc5b658c27cb6341177f205fd67@xs4all.nl> CC: From: Marco Tiloca Openpgp: preference=signencrypt Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAHNJ01hcmNvIFRpbG9jYSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIb AwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bV ZKqD92JNWDTX6h1MUsgejwj4RXs6UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s8 6ncVygiDUh9fbSDTcuzOp2qgu9nsc8sEsYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK /OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4MxMhmi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST 0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0KnXlAczWxCD3J3XTFK4MES/b3n3oc2GJY8I+ tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZszJeTvsMvc7ATQRUjXkVAQgAlpqfpOi5 GOP3su3gO7pmFXNtoslagBF5ssA2MxI3sGMEXI06x/zcdRKsIyA7lvgQRKDC0WThwoJo6Oh0 ZliLrXGFQrfYnqJLpbZKK/QQaEFT4iPk6edTqdNon5BnKxEDWYu6t35jrYRWcGejSZ1GwNm8 nGimfKApbwwkI+gIxMnQT50u91GhKA7KrBlY2cAoXzjIOTshZvdEI6SMPJtLg1XAsyin8at0 /8+7ckYLnCFHvOBMwbriQREhIyv4RdJ0diw4dUoQ9vRVqxWUjVVQlbtVGGSwGsn/KCihx6TP sIX4xGDuF7A6VeM0NeQPg9eR0Yh0egHX+Dw7TzNQwsIIIwARAQABwsBfBBgBAgAJBQJUjXkV AhsMAAoJEO4mZLQOWNpDxhMH/1jY08t8++Ly5h8nFbBV16EPFtfvOfJkcgHdGvCWM2N8Qewl baiNx8vPeEHMOB+hu/fQNTi/QdRHgPGI92js9DW1Mn+RlvoqLa94fPiiAjmGd+PwUGji83bw zZkaBh5/jXk84Re3knojyoto3sfjVaHYYzlRl8PBIWBpHmS78pxxG6IizOE28j21UfR7HVai hlUw8SkhN52pqN5L7WOrMkRSIlM+VsyX2ALqm7ept08QxG/LAPac2i7oZn5yUXNdh+TVWRGZ hPxJCRU5ZD+MJ2cjkn/69v1XdIh2rgcL+e3KWOhxRTHu67yuLOzBOc3LThJcuQujQrtWWjbX VLqg0jw= Message-ID: Date: Fri, 29 Jun 2018 17:36:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <0c356bc5b658c27cb6341177f205fd67@xs4all.nl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wZdc8f6Sf6JeTUi2GHhhR1u8qSeGgn1sQ" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: marco.tiloca@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [Ace] ace-oscoap-joining comments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 15:36:17 -0000 --wZdc8f6Sf6JeTUi2GHhhR1u8qSeGgn1sQ Content-Type: multipart/mixed; boundary="MjsSEPhnmWWIqctrZkgAfMMedHI8qB2Uv"; protected-headers="v1" From: Marco Tiloca To: consultancy@vanderstok.org Cc: ace@ietf.org Message-ID: Subject: Re: [Ace] ace-oscoap-joining comments References: <0c356bc5b658c27cb6341177f205fd67@xs4all.nl> In-Reply-To: <0c356bc5b658c27cb6341177f205fd67@xs4all.nl> --MjsSEPhnmWWIqctrZkgAfMMedHI8qB2Uv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello Peter, Thank you very much for your review! Please, find our answers in line. We took into account your comments for producing the latest version of the draft [1]. Best, /Marco [1] https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-04 On 2018-04-19 11:36, peter van der Stok wrote: > Hi authors, > > Below comments on the draft-tiloca-ace-oscoap-joining-03. > The draft seems to be pretty clear, but then, I did not try to > implement it. > > Comments on details, typos, structure, and questions are mixed > together in reading sequence. > > title: I expect draft-tiloca-ace-oscore-joining (oscoap is in the past)= > [MT] Indeed, however we would need to submit a new version -00. > page 3 section 1. dtls-authorize and oscore-profile are mentioned > quite prominently here, but almost not used elsewhere in the draft > (section 6), and only informative. suggest to remove here. [MT] We have removed the references from this paragraph, and made dtls-authorize informative. However, we think to keep oscore-profile normative, due to a number of COSE Key parameters used in the Join Response (Section 4.2) and defined in the OSCORE profile document. > > section 1.1 The phrase "message exchanges .... useful terminology" may > go for me. (mentioned in authz and others already). > Is reference to oAuth 2.0 not sufficient, ace-actors is not really > needed IMO. [MT] We removed the sentence and the following reference to ace-actors. > > I miss Group Manager in the terminology. here relation with RS can be > mentioned, not needed in section 2. [MT] The paragraph pointing at OSCORE and oscore-groupcomm has been extended as follows: "These include the concept of Group Manager, as the entity responsible for a set of groups where communications are secured with OSCORE. In this specification, the Group Manager acts as Resource Server." > > Section 2 bullet 3 is quite complex text: > Suggestion: > The Authorization Server (AS) authorizes joining nodes to join .... > The AS MAY release access tokens for other purposes than accessing > join resources; for example: to release...... > of OSCORE groups [MT] We took into account your suggestions and rephrased the text. > > Page 5 > Is paragraph "All communication ...... ACE Framework [authz]" not > almost identical to > "communications between ..... this specification". If not, > reformulation is clearly needed. > [MT] We reformulated as follows: i) a first single-sentence paragraph points at secure communication based on CoAP; ii) a second paragraph on the secure communication required between joining node and Group Manager; and iii) a third paragraph about secure communication with the AS, either between the AS and the joining node or between the AS and the Group Manager. > page 5 point 1. suggestion for last phrase: With the response from the > AS, the joining node starts or continues a secure channel with the > Group Manager. [MT] We rephrased the text as: "The joining node will start or continue using a secure communication channel with the Group Manager, according to the response from the AS." > point 2 Collapse phrase 2 and 3 to: "Then, a joining node must > establish .....first time".=C2=A0 May be add a reference to DTLS or oth= er > recommended alternatives? > [MT] We rephrased the text as: "After that, a joining node must have a secure communication channel established with the Group Manager, before starting to join an OSCORE group under that Group Manager (see Section 4). Possible alternatives to provide a secure communication channel include DTLS [RFC6347] and OSCORE [I-D.ietf-core-object-security]." > point 4 in the OSCORE group -> with the OSCORE group members. > [MT] We rephrased it as "with the other members of the OSCORE group". > Suggest a point 5 to say that the secure channel is maintained for > between JN and GM [MT] Done. > > Section 3 is about JN to AS but mentions secure channel between JN and > GM. That is confusing, because I expect text about secure channel > between JN and AS. > I suggest to remove the discovery with the aid of resource-directory, > or add more text and specify a resource-type rt=3D) for the AS. > [MT] We have rephrased to put more focus on the exchange between JC-AS. Also, we removed the text pointing at the discovery based on the Resource Directory. > section 3.1 under scope parameter first *: I failed to find the > "dynamic" component of the scope parameter in [key-groupcomm] > [MT] Sorry for the confusion. What is dynamic, or actually variable, is not the "scope" parameter and its size, but part of the value of the actual Gid associated to the group. This is to admit Gid formats with multiple parts, some of which are dynamic in value, such as the case of Group Prefix and (variable) Group Epoch (see Appendix C of oscore-groupcomm). [MT] We have rephrased the second sentence as: "The value of this identifier may not fully coincide with the Gid value currently associated to the group, e.g. if the Gid is composed of a variable part such as a Group Epoch (see Appendix C of [I-D.ietf-core-oscore-groupcomm]= )." > get-pub-keys. I wonder why you want to separate the public key storage > from the GM. What is the operational advantage?; I only see added=C2=A0= > complexity. > [MT] The oscore-groupcomm document defines a "broad interface" where public keys of group members can alternatively be stored at a separate trusted repository other than the Group Manager. However, oscore-groupcomm does recommend that the Group Manager acts as public key store (see its Section 6). [MT] To keep consistency, we are preserving both the same possibilities also in this document. Do you think that this ACE-based approach should explicitly be limited to the Group Manager as public key store? [MT] We have anyway removed the get_pub_keys parameter from the Authorization Request, also based on a discussion with Jim where we agreed that the AS has no actual reason to know about this specific wish from the joining node. > section 3.2 "The AS is responsible.....Group Manager" I don't > understand this phrase. > [MT] Now rephrased as: "The AS is responsible for authorizing the joining node to join specific OSCORE groups, according to join policies enforced on behalf of the respective Group Manager. > The "exp" parameter; it MUST be present and then is out of scope? > [MT] That was ambiguous, we rephrased it to be more aligned with Section 4.2.2 of RFC6749. What is out of scope if defining alternative means usable instead of "exp", hence required to be mandatory. > The phrase "in case the value......include the "scope" parameter" is > difficult to read. > I suggest: The AS must include the "scope" parameter in the response, > when the returned value of the response differs from the one in the > request. (or anything shorter) > [MT] We took into account your suggestions and rephrased the text. > section 4 page 7 > /what specified/ what is specified/ > [MT] Fixed. > section 4.2 page 8 > /yields to a positive/yields a positive/ [MT] Fixed. > > section 5 > Again why separate key storage > [MT] See reply to the comment above. > first bullet: IMO, it does not hurt to provide the public key, when > already known; specifying conditions in the protocol=C2=A0 increases th= e > probability of errors. (Others may have different opinions given the > need of payload reduction) > [MT] Good point to consider. We have rephrased the last sentence as: "In this case, the joining node may not provide again its own public key to the Group Manager, in order to limit the size of the join request." > page 11 > "Before sending the join response .... this specification" suggest to > move this phrase to section 6. > [MT] Done, now placed right before the last paragraph of Section 6. > section 6. I suggest to add the reference to oscore-groupcomm when > referring to the (sections) or (appendix). > [MT] Done. > Hope this helps, > [MT] It definitely does, thanks a lot again! > Peter --=20 Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society. --MjsSEPhnmWWIqctrZkgAfMMedHI8qB2Uv-- --wZdc8f6Sf6JeTUi2GHhhR1u8qSeGgn1sQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJbNlHgAAoJEO4mZLQOWNpDHaQH/jpwUEJSD7VB1vIjG8BKy6Wv LKEh3FIjben9tVFmoPAHWSYSni7FEaf52yNs6hTjsbL20YIHke45zhS3JnFoujU9 /quGMYrfdC+YvfH/uscBgegwtcf4yTSGP7LR9/7C38Uj2mQ94wxwgKLBSfibpChC QequiBwenfPt83x5NSMMRruyvv5g8nep1N5KB1U5zqBw4QSWv83C+s04lqXd0A7a jz5GfnTuNnajehLYZE7z5KjAfmjE93IygasA3QVvpUiJvde39a5pDfZSF+x3RxRa dRvBGz+Rj2BaUquDbndzBUO9o/SU9YC2jj/F53X6IcO0iv7Z/PzgfR22w1uqu4Q= =HUE8 -----END PGP SIGNATURE----- --wZdc8f6Sf6JeTUi2GHhhR1u8qSeGgn1sQ-- From nobody Fri Jun 29 13:36:36 2018 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 8123D130EBE; Fri, 29 Jun 2018 13:36:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153030457748.30446.11300640396199936379@ietfa.amsl.com> Date: Fri, 29 Jun 2018 13:36:17 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 20:36: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 : Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) Authors : Michael B. Jones Ludwig Seitz Göran Selander Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cwt-proof-of-possession-03.txt Pages : 15 Date : 2018-06-29 Abstract: This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cwt-proof-of-possession-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cwt-proof-of-possession-03 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 Fri Jun 29 14:02:06 2018 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 AF2641294D7 for ; Fri, 29 Jun 2018 14:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 UmNF0UQdVKuJ for ; Fri, 29 Jun 2018 14:02:01 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0109.outbound.protection.outlook.com [104.47.53.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2537F130E74 for ; Fri, 29 Jun 2018 14:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Adf+q/4FQg8gmcbe0kqvpmCtgMWyWeNt01SiD5/2jN8=; b=BgxX7G6ikzW7uvkvDebOzxrF43AwcQTOj50aX8Kv8cMr1A9HP02UG6tCL/WISVBdwYcM9anZJbhrwWK0lV/dcxLoTW91WPBx2Vti22K0lbq5egaIQT/jyEWkdpekRSvROnkshJY396+xv/OVq0m09/jZAKkasbF6YzKwxZVGxXA= Received: from DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) by DM5PR00MB0309.namprd00.prod.outlook.com (52.132.128.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.949.0; Fri, 29 Jun 2018 21:01:59 +0000 Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::6944:e7f0:d402:b507]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::6944:e7f0:d402:b507%9]) with mapi id 15.20.0949.000; Fri, 29 Jun 2018 21:01:59 +0000 From: Mike Jones To: "ace@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing WGLC comments Thread-Index: AdQP6kwTew3S+l25S6+XJdj34t8FmQ== Date: Fri, 29 Jun 2018 21:01:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.130.116.117] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0309; 7:SgYW2pPowVI/+KpMmCc8fgTMqAgpZ5BVul8OzSAVl0JioOUUJXVIN+52dlsEa6D0NBoUVsaP+bagZ6wUfnp4xbQObv3JdfXvxGov8Jr/wIGDY2DNRRIDldhzw8vljwUa6AdkXei/RoaNqJqF5ZQT5zIZB84fP1YamRfTjIL8bqEmnY7xWTP6MG4Hlz6vb8DCVRwpYp3fG2w8Gjg4LPRWjgFohwBq8BppTTxLtRtESBUKrV2DIhNJ2kCLnyKlBZ6d x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 971f0935-ea0c-461a-770b-08d5de038e08 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(48565401081)(5600045)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:DM5PR00MB0309; x-ms-traffictypediagnostic: DM5PR00MB0309: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(31418570063057)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(93006095)(93001095)(3002001)(3231270)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR00MB0309; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0309; x-forefront-prvs: 0718908305 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(136003)(39860400002)(346002)(209900001)(189003)(199004)(9686003)(5640700003)(81166006)(186003)(486006)(55016002)(53376002)(790700001)(316002)(6116002)(476003)(1730700003)(81156014)(5250100002)(2501003)(22452003)(3846002)(25786009)(106356001)(8990500004)(53936002)(606006)(8676002)(7736002)(54896002)(105586002)(8936002)(74316002)(2351001)(478600001)(10290500003)(86362001)(10090500001)(6306002)(2906002)(14454004)(966005)(256004)(26005)(68736007)(86612001)(97736004)(102836004)(21615005)(6916009)(72206003)(5630700001)(6436002)(66066001)(6506007)(236005)(5660300001)(14444005)(6666003)(33656002)(2900100001)(7696005)(99286004)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0309; H:DM5PR00MB0293.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RR3t1vVmSaZEhWFb1czw3Rz8kLxmM0sDhw9bvJOacye91Zf5Uov9xXvI6YMvXKqW4PQoEsH+9vzODkxro6S/NU4taZWIZKWwcPbElc7yXNhdhnVeFpuUAg9eM/oqFfn/Bx7HcD1UR/qPw59BtPDcRSGb37j/YYTOLiZvhsdkm/krdQKdgimrCcONXrPD0m3lvCM+tb8ZiMppJ8uJCrf4a1pe2w7yR9kxcDlqX/4AuvIZw3qXlOa1xhbUihj77EhPoEvy+nIVRXKJeRFetenRi1TD4p5Q3YjE5b4kwbkEz5a8bRTFDBH9xiVay3Gc+W2/Z3Wy5/WdDfzuqUi0WPSA5uINOaCB9+V81VE2QmiMIm0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0293BA8987B7A49DA5C9BEE7F54E0DM5PR00MB0293namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 971f0935-ea0c-461a-770b-08d5de038e08 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2018 21:01:49.4461 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0309 Archived-At: Subject: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing WGLC comments X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 21:02:04 -0000 --_000_DM5PR00MB0293BA8987B7A49DA5C9BEE7F54E0DM5PR00MB0293namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new draft of the Proof-of-Possession Key Semantics for CBOR Web Tokens (C= WTs) specification has been published that addresses the Working Group Last= Call (WGLC) comments received. Changes were: * Addressed review comments by Jim Schaad, see https://www.ietf.org/mai= l-archive/web/ace/current/msg02798.html * Removed unnecessary sentence in the introduction regarding the use an= y strings that could be case-sensitive. * Clarified the terms Presenter and Recipient. * Clarified text about the confirmation claim. Thanks to Samuel Erdtman and Hannes Tschofenig for contributing to the edit= ing for this version and to Jim Schaad and Roman Danyliw for their review c= omments. The specification is available at: * https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-ace-cwt-proof-of-possession-0= 3.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1885 and = as @selfissued. --_000_DM5PR00MB0293BA8987B7A49DA5C9BEE7F54E0DM5PR00MB0293namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new draft of the Proof-of-Possession Key Semantics= for CBOR Web Tokens (CWTs) specification has been published that addresses= the Working Group Last Call (WGLC) comments received.  Changes were:<= o:p>

  • Addressed review comments by Jim Schaad, see https://www.ietf.org/mai= l-archive/web/ace/current/msg02798.html
  • Removed unnece= ssary sentence in the introduction regarding the use any strings that could= be case-sensitive.
  • Clarified the terms Presenter and = Recipient.
  • Clarified text about the confirmation claim= .

 

Thanks to Samuel Erdtman and Hannes Tschofenig for c= ontributing to the editing for this version and to Jim Schaad and Roman Dan= yliw for their review comments.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1885 and as @selfissued.

 

--_000_DM5PR00MB0293BA8987B7A49DA5C9BEE7F54E0DM5PR00MB0293namp_--