From nobody Fri Sep 3 11:33:46 2021 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999AA3A2805; Fri, 3 Sep 2021 11:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 lj6cnqDXIH_6; Fri, 3 Sep 2021 11:33:16 -0700 (PDT) Received: from mx01.puc.rediris.es (outbound6mad.lav.puc.rediris.es [130.206.19.150]) (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 94E403A2801; Fri, 3 Sep 2021 11:33:15 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx01.puc.rediris.es with ESMTP id 183IX6s5030498-183IX6s6030498; Fri, 3 Sep 2021 20:33:06 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 0857220A9C; Fri, 3 Sep 2021 20:33:06 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Uuqrg-fEXFSN; Fri, 3 Sep 2021 20:33:05 +0200 (CEST) Received: from [192.168.9.127] (unknown [84.78.251.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 891EF2020F; Fri, 3 Sep 2021 20:33:01 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <78D49A4D-AE9D-4701-9ADF-DAF8ABB317ED@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_F93A85EF-C1BC-4F81-83B3-D3D34D2BA90C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 3 Sep 2021 20:32:59 +0200 In-Reply-To: Cc: Rafa Marin-Lopez , Dan Garcia Carrillo , EMU WG , "ace@ietf.org" To: =?utf-8?Q?Christian_Ams=C3=BCss?= References: <07cd0942-9ee0-b124-b3a7-649f262d7c9e@uniovi.es> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-FEAS-SPF: spf-result=pass, ip=155.54.212.171, helo=xenon44.um.es, mailFrom=rafa@um.es Authentication-Results: mx01.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=rafa@um.es X-FE-Policy-ID: 2:15:0:SYSTEM, 2:15:1:uniovi.es DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=wK4VT/Eu+KjPdg6IxicDph3LE1498zPWZkGl1uh9rFg=; b=QyF28XgKoN8UAtFfotVnIF0A+Zh02//TQRA5yej1uADTnH/sepNYDOOkh54yKoIm9r9CBcUm9Sjh tAh/ertDyIP1+xOzEFw00R4ee6qeXxfDDXGx9D0f0iXAipzNycH4PSyvDjXVGV/emz6zYDRuVBxy IwrKqVQOUFDE8mfIxRaUaXdCX1r8kvag0QH2S6QEat7Zy0Nxb0qkvWpH6pREB5SYLg39FhE/FDu7 3o9s4qUrthyvSxP+gwKM/yuwqLNvYgHRoISBML7p3CyeJoMCuGcSDb1jAuyvXDP9RgpZFxN4JaG/ yQ0mAQ6FChXKQ6nMxfQljSjJZYwOLo5XVTdBhQ== Archived-At: Subject: Re: [Emu] [Ace] About securing last exchange CoAP-EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2021 18:33:22 -0000 --Apple-Mail=_F93A85EF-C1BC-4F81-83B3-D3D34D2BA90C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christian: Thank you for comments. See our comments inline. > El 16 ago 2021, a las 16:52, Christian Ams=C3=BCss = escribi=C3=B3: >=20 > Hello, >=20 > On Sat, Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo wrote: >> As such, CoAP server (left side) could not see the content of the = CoAP >> message (message 7) without deciphering it. Moreover, as the URI-path = is >> also ciphered we cannot point to the right application to process the >> message to achieve an alternate indication of success. >=20 > If the recipient ID were available a bit earlier (and not derived from > the MSK), would it then be viable to infer from the OSCORE ID that = this > is the last message, process an "EAP success", and start derivation = just > to extract the session lifetime (and thereby confirm the keys)? What you mentioned was something we already considered but we do not see = how it would solve the problem. Let me explain. According to OSCORE RFC = , Section 8.2 - step 2: "If either the decompression or the COSE message fails to decode, or the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, then the server SHALL stop processing the request.=E2=80=9D What you mention solves step 2, however the step 5 says: "If decryption fails, the server MUST stop processing the request and MAY respond with a 4.00 (Bad Request) error message." However, the OSCORE context with Recipient ID does not have any = Recipient key yet, correct?. To make this work, we believe this should = happen. 1) The CoAP server should create an OSCORE context with ID but without = any key material. 2) When the CoAP message contains the OSCORE ID that hits the OSCORE = context without any key material, we would have to assume this is = CoAP-EAP: the OSCORE implementation should not discard or give a fail = for this coap message but "pass the control" to CoAP-EAP so that we send = a altAccept to the EAP state machine so we get the MSK. 3) =46rom the MSK, we derive the OSCORE key material for the OSCORE = context with the corresponding ID and update the OSCORE context with = this key material=20 4) Verify that the received protected coap-message with OSCORE. 5) Then we can get the cleartext information. For us, this seems a little odd and we do no think it is supported by = OSCORE RFC, are we wrong? Any comment is welcome. Best Regards P.D: Dan is processing your review of the I-D. Thank you very much. >=20 > (That'd be all assuming that the "EAP success" contains really just = the > EAP success code and no further information, which would be = "compressed" > into the "some OSCORE is sent on this" information, and that the > Session-Lifetime does not need to be known to advance the EAP state > machine). >=20 > BR > c >=20 > --=20 > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_F93A85EF-C1BC-4F81-83B3-D3D34D2BA90C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Christian:

Thank you for comments. See our comments inline.

El 16 ago 2021, a las 16:52, Christian Ams=C3=BCss <christian@amsuess.com> escribi=C3=B3:

Hello,

On Sat, Aug 14, 2021 at = 01:37:06PM +0200, Dan Garcia Carrillo wrote:
As such, CoAP server (left side) could not see = the content of the CoAP
message (message 7) without = deciphering it. Moreover, as the URI-path is
also ciphered = we cannot point to the right application to process the
message to achieve an alternate indication of success.

If the recipient ID were = available a bit earlier (and not derived from
the MSK), = would it then be viable to infer from the OSCORE ID that this
is the last message, process an "EAP success", and start = derivation just
to extract the session lifetime (and = thereby confirm the keys)?
What you mentioned was something we already = considered but we do not see how it would solve the problem. Let me = explain. According to OSCORE RFC , Section 8.2 - step 2:

"If either the
    =    decompression or the COSE message fails to decode, or the = server
       fails to retrieve = a Recipient Context with Recipient ID
       corresponding to the = 'kid' parameter received, then the server
       SHALL stop processing the = request.=E2=80=9D

What you mention solves step 2, however the step 5 = says:

"If decryption fails, the server MUST stop processing = the
          request and = MAY respond with a 4.00 (Bad Request) error
  =         message."

However, the OSCORE context with Recipient ID does = not have any Recipient key yet, correct?. To make this work, we believe = this should happen.


1) The CoAP server should create an OSCORE context = with ID but without any key material.

2) When the CoAP message contains the OSCORE ID = that hits the OSCORE context without any key material, we would have to = assume this is CoAP-EAP: the OSCORE implementation should not discard or = give a fail for this coap message but "pass the control" to CoAP-EAP so = that we send a altAccept to the EAP state machine so = we get the MSK.

3) =46rom the MSK, = we derive the OSCORE key material for the OSCORE context with the = corresponding ID and update the OSCORE context with this key = material 

4) Verify that the = received protected coap-message with OSCORE.

5) Then we can get the cleartext = information.

For us, this seems a = little odd and we do no think it is supported by OSCORE RFC, are we = wrong?

Any comment is = welcome.

Best Regards

P.D: Dan is processing your review of the I-D. = Thank you very much.


(That'd be all = assuming that the "EAP success" contains really just the
EAP= success code and no further information, which would be "compressed"
into the "some OSCORE is sent on this" information, and that = the
Session-Lifetime does not need to be known to advance = the EAP state
machine).

BR
c

--
To use raw = power is to make yourself infinitely vulnerable to greater powers.
 -- Bene Gesserit axiom
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_F93A85EF-C1BC-4F81-83B3-D3D34D2BA90C-- From nobody Fri Sep 3 12:24:03 2021 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC823A2A50; Fri, 3 Sep 2021 12:23:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unioviedo.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 E-fvEB7vfvDw; Fri, 3 Sep 2021 12:23:43 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70059.outbound.protection.outlook.com [40.107.7.59]) (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 4E0DD3A2A4C; Fri, 3 Sep 2021 12:23:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BXk2e6dF3E2HqnFy0JQeOcxgv6t/lmBSVG1BB0WTbyLI4DN/8Myy16pcxbC4TEsxd6Q+0aghWQER3hhg1lPH1z5M0xP0tf81YlTpN2EJiDP9O6VCvrUrOspdycr+V/0NbGJQmxPo3owK8iJHCQ+lT3SNu+jBgwP7gUNpwd2V4HyL7zvmeUrqmcui0Kr66o7njFzLnJ2NrAhStSG0ZuPCqQpY2qNP4Kns+LKJgXyJHZyBXbxCtxLfPG6sxcqvLaGJe8n7xCfQp31jIBX6gkCXngy2mbDkWenQkuzb/Tvy095i2hc5vO+Eb55Juo4g2/3JitqDace3s7IlTrNYNx69Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I1lo7m4V4lZ4+Z1zY98LJTMAioD21XNUq3w5SQDhidU=; b=gH5agNsd7osZrBpQmsMf/UthNVitACT/PAp7VaJ8vjVOmddvcZc2OaTHYsmkLPF2KQEmQw8YiRED6ddGRSX0H/NAqjzkQJk2lr23Ihv4Yxo1xmoA4KTRkPCrvFKwLOntqi39MRiaCUNHQMk4Q15nQd+zFKLoXKNyV2tRgcB28bcpLZl21mBaYWD55t/1KYPjhjZSwFn/JYbFMTVepg+/kaOaBzk3cEKp13DuqhYhPWIJyJCLf9Qka5aM6OEHnfleybOwP7LKjQUBCTxeHZMuLUm9/5HitnTFAO/FHG287K2EDvRWDwiOdnY3pb0ksfJlE94EgAY3wXvxJIqstDvPsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I1lo7m4V4lZ4+Z1zY98LJTMAioD21XNUq3w5SQDhidU=; b=QCp2iLtSo12bez8gNBZkH6MkpXH1RSCII9vXOx5AYPv9Tabk1cylJR9J3dmMO8C0dGK3ogvhoodTztBblZbvYP9t4q/T15BKsKfdWFN/ImlHEXWPCGoM1Qr7ofk27fgYnqdUj9sfwEXD35fXFZN15UffZpntaDNQAgP7uDHKGIU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=uniovi.es; Received: from DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) by DBAPR08MB5704.eurprd08.prod.outlook.com (2603:10a6:10:1a1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.21; Fri, 3 Sep 2021 19:23:38 +0000 Received: from DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::70e4:c7c8:b279:2395]) by DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::70e4:c7c8:b279:2395%8]) with mapi id 15.20.4478.022; Fri, 3 Sep 2021 19:23:38 +0000 Cc: garciadan@uniovi.es, EMU WG , "ace@ietf.org" , Rafa Marin-Lopez , core@ietf.org To: =?UTF-8?Q?Christian_Ams=c3=bcss?= References: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es> From: Dan Garcia Carrillo Message-ID: Date: Fri, 3 Sep 2021 21:23:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: LO2P265CA0022.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::34) To DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from DansMacBookPro.local (212.102.48.73) by LO2P265CA0022.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Fri, 3 Sep 2021 19:23:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8eff5d37-32bc-4c2a-6a2e-08d96f10548b X-MS-TrafficTypeDiagnostic: DBAPR08MB5704: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fYrj/mgApcZZyRrabeML3tJY3Tx1gYzmOxN3Rzh++NrGSDaUF3DP7ytAChrLk4vqQTKrYvYRPCPU5GtyxLx2xhylfp2ZqBTot9y85oMz8uYKJWqPx2WZCX8LBVV5qRRVuvEFv7jTlkd3Dk6DtCTOyy3Q7XbD2owqj5RBuQM8QWmhlQD7mjVuFzvsmFp1diXElTH2T9jrit2xnplUJMgbh/XPYMMbalnwW0VR8Ita/R1Px3xSwC6pSMM80xbEZkap1seSZU9DsJmEBtCO7O0Jr6TP6XWoGkM0DpDsCLBjtJDwWGCurYdiqbonI7s2OVfRNPc6yA/+KnQFLBjJsOaak8k6WY4wEoNv4KA3rIFpS6mm0VNW2w8NDL+AJYbrj4DNgCJoEmH7Fn9Hx3ihssmZV0K9Xbm0g9FyoeWDz06yQayFO0vKUAJ0J/UwL7OiPCwAtpdFx/UZYsYbhLFJa2hTYnPkxNR3YmdK9wDfSy40Xp2/hZnOGCbVOwdpfOkVKmkoxWC1GUq4mZ95DpW6FkQwE9xzB2rtynMy6LfKE8GJZ8cID7XfSyjdw+7bnIp5jrCnA0EF2n2y++024Ial1ov2Pa3N5IJV5Ds2L4SDEe7EIudvzIu4v+bATr0ugs3SqNRVtyP9KKAJTelM/tbaUaFzlE0XUokghnSqo8ntVSbH0RRmOKiYibRiQ+orkCABR9+sMeIubaTsMeRLGiqqzxYWVzXKK4lq4HeCfF0oFvbAW4LBV+VzKCy6vk9cIkr+q7gYqrIkPvonqsQLidnvkssnayJ2EOoowjTi+nkllopzSc8hqCrFtp9X2Ld6/kTZ9rJgcdtgkH0wxZKNK+y4yhstpQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB6202.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(2906002)(316002)(186003)(31696002)(36756003)(38350700002)(66476007)(66946007)(6486002)(86362001)(30864003)(66556008)(6506007)(53546011)(8676002)(26005)(966005)(66574015)(6512007)(5660300002)(52116002)(2616005)(83380400001)(54906003)(8936002)(6666004)(4326008)(31686004)(38100700002)(956004)(508600001)(6916009)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R0VPY2tSU0hLVEIzSzlKbG5YWG9nNVFQbTJ1L3IxNURrSTdQajlYZzMyUUhx?= =?utf-8?B?U0U4NWlHelpUcWkwV3J5S3Y0ZkhNck91Z0N6S1NsYmFqRnFzZEU4ekoxYzd5?= =?utf-8?B?WHVwWEVUSTFOcVFpMTlHd0tHM1IxZGJhVzB5d0VST0hMQTNJL3V1RGdIdjRP?= =?utf-8?B?YzhSMXhHekhIbEdFRTk4TXZWUGFZV1FHVGZZSklCSldoNUJ2VHNtajdTOFlq?= =?utf-8?B?bGlDTHRhT1FRanlsTmkrYzJ0dUZjM0pCZmlaSkFVUStVaWdRKzcyTE5MMDA0?= =?utf-8?B?RWxhWFJidUsxWTlvU0JCV2k0WlNDYmNXUFFEUVlBckV3eVJPQTdBZHF0a1Q4?= =?utf-8?B?QTh3WHRyMlpacE14SXY4WXcrUENNTGRLaWN4UHVVaXFLYnR2bFFMMXA4TkZ5?= =?utf-8?B?UXZHVkcyRFd4S25MR3dRR1psVGVKNmc3dHdDUlFNZkIvdDcvNEJRdEdCeDZv?= =?utf-8?B?TEJaYnVUTFBJZkIzUkJkeTQrNHlnbEJMTEJQejNTWG1ybERnQ0xKWlZUQTVG?= =?utf-8?B?N1dOWXFva1NVTWcrZ282NmtkWFJEdXhFUEtQdGlkM0loaW1NVHl1dEJsWnM2?= =?utf-8?B?a2I0cDU4MGw5amFIK0tLNVlrRFpaZXJDSHNnZ2h6RWtJV2RPa00vc204Y1Z1?= =?utf-8?B?UXBrWkluRFVMZXZucXYxeTlOZVh0WDBSQ2xlWkpWcE44TDVwTGcxMDhsVkt1?= =?utf-8?B?eDhWOXZpbHFLcTBsYWdUeSs3VkQrT2tWMDhubEM4dER4MmdqY2hpOGdvL0I4?= =?utf-8?B?bklBVjJRR1MvdThORnR2UXpsNHljbUtpaldHcG04Z0pQdno3aFhVcGFlVHRE?= =?utf-8?B?WjdjUUcrZHVFaEg5MXNYa3Mzdm5RdHJhWnlRaWZ1Z0RrTHBMOXFjQ0N5MkhU?= =?utf-8?B?MnZCTlpxam55SnhBNWU0QzFzNUEwWDJDSVFEOVlSemNiV2pPem50LzExaHd0?= =?utf-8?B?YWh1VG5IMDB5MjVqRVM0UjQyV0wrVjRXdytud1FKWkJjR0ZjZXA3T2J2N2lk?= =?utf-8?B?RTNrdDJZcjhUaFZxeWlxZkhIUHkvcDU1djFySWZoWjl2MzZkd09HR2ZtRkZ6?= =?utf-8?B?T2VxQmljSVk1S0xPekFmTW96TU1oUXJFaWdrbldldUZURGtMMnVtOVFWVnly?= =?utf-8?B?ZzFScGNDU1Z6bVpaWHlFVTZocFZTSzN5WU9tT3hHeEMyaERBcmNwYTg0bXpp?= =?utf-8?B?dlFiU3lYZ2UyQS94Nm04NW9ib1FKN2s0M3NNd1ZhSkNnVW1qM3VqWWRhalU2?= =?utf-8?B?R0ZEdjVyUzU0c2lmYXl3UFMwdzlrM2hjSGxpZjViS3NSYnhtMHMvTGlYbmVi?= =?utf-8?B?NU42TGxNODVTaGRwODRNZXRtNjk3Q003R01OWFZ5NWVSYXBSZldjVGxYK3pi?= =?utf-8?B?M2kvQko2amlrWDc4eHhvWDU5RFVuZ1p2aVA5MzNHdzVqcUx2ZjFyUVhHM0Fp?= =?utf-8?B?N2pwc3MwRU85RUhacWtOcUhqM2xQb1dKL2tULzNuYjJFRjlKVEM5K0g3ckdW?= =?utf-8?B?aW9FWG8yMURwNVlWeHFMbkpQNmpiMC9aeURrSS8xazJLUmFEOU1rdWtZMjJU?= =?utf-8?B?MUxnd2hjZ0FucWxzQURTMlNCUjdNN3ZiaW81N1o4MFc1cWxQL0NrVUkxaDNp?= =?utf-8?B?Wmt3ZE9TeW43NmxGLysvL3RQR2l2bEY1QWR5OUUxK2hVUEgyMnhmRVpsb0ZB?= =?utf-8?B?VmNZSkhFNlRwV1BpbkxOWnJIei9ja1BqeFpMQ3VoZGtzRk5rVXRHajk1NTF5?= =?utf-8?Q?KFkb/ZHsoFFkHY8NuKbv9W3Ti54ijGKbSHX3M9R?= X-OriginatorOrg: uniovi.es X-MS-Exchange-CrossTenant-Network-Message-Id: 8eff5d37-32bc-4c2a-6a2e-08d96f10548b X-MS-Exchange-CrossTenant-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2021 19:23:37.9881 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PEAfkvBpWxkTskohVjP0WAGDkNdgfvvid+xRc+LDxliPeaMsY954Vhbd8wpPUg7QLdZjP5RXZ4OtAqT8VGafyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5704 X-MS-Exchange-CrossPremises-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 06 X-MS-Exchange-CrossPremises-Mapi-Admin-Submission: X-MS-Exchange-CrossPremises-MessageSource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 212.102.48.73 X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: DBAPR08MB5704.eurprd08.prod.outlook.com Archived-At: Subject: Re: [Emu] [Ace] CoAP-EAP draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2021 19:23:49 -0000 Dear Christian, Thank you for your detailed review. You are raising indeed very interesting points. Just came back from vacation and we will respond as soon as possible. Best Regards. On 16/8/21 16:40, Christian Amsüss wrote: > Hello CoAP-EAP authors and involved groups, > (CC'ing core@ as this is a review on CoAP usage), > > > I've read the -03 draft and accumulated a few comments; largely in > sequence of occurrence. > > Over all, the protocol has improved a lot since I've last had my eyes on > it. Several comments below are about how prescriptive the message types > are. I believe that this should be resolved towards generality, or else > the usability of this protocol with generic CoAP components will be > limited (or, worse, still implemented and then surprisingly > incompatible). > > > * Figure 1: For readers new to the topic of EAP, I think that it might > be useful to extend this to cover also the EAP server or AAA > infrastructure, if that can be covered without too much complication. > > Suggestion (without illusions of correctness): > > IoT device Controller > +------------+ +------------+ > | EAP peer/ | | EAP auth./ |+-----+[ AAA infra. ] > | CoAP server|+------+| CoAP client|+-----+[ EAP server?] > +------------+ CoAP +------------+ EAP? > > \_____ Scope of this document _____/ > > Figure 1: CoAP-EAP Architecture > > * `/.well-known/a`: [note: May be irrelevant, see next two items] > > If the designated experts don't go along with a > very-short option (I'd kind of doubt you'd get anything shorter than > `/.well-known/eap`) and if that puts you up against practical limits, > using a short-hand option might be viable. > > So far there's no document for it and I've only pitched the idea > briefly at an interim[1] (slides at [2]), but if push comes to shove > and you need the compactness, let me know and that work can be > expedited. > > [1]: https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core > [2]: https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/slides-interim-2021-core-05-sessa-core-option-for-well-known-resources-00 > > * Discovering the Controller is described rather generically, but with > CoAP discovery as an example. > > As long as CoAP discovery (as per RFC6690/7252) is used, that already > produces a URI, which can contain any path the server picked. It has > thus no need for a well-known path. > > Are there other discovery options envisioned that'd only result in a > network address? Only for these, a well-known path would make sense. > (And then it's up to the envisioned client complexity if one is > warranted). > > For comparison, RD[3] explores some of the options. A path may be > discovered using CoAP discovery as `?rt=core.rd*` right away from > multicast. Or an address may be discovered using an IPv6 RA option, > with CoAP discovery acting on that address. Only for cases of very > simple endpoints, it also defines a `/.well-known/rd` name that can be > used without CoAP discovery (and thus link parsing) happening > beforehand. The same rationales may apply for EAP (the devices using > the resource are mostly servers, otherwise, and send a very simple > request to start things), but again that's only if the address was > discovered through something that's not CoAP discovery already. > > [3]: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-rd-discovery-and-other-inte > > * For message 1, why does this need to go to a fixed resource? There has > been previous communication in message 0 in which the resource could > have been transported. > > Granted, it's not as easy as in messages 2-to-3 etc where the > Location-* options are around, but the original message 0 POST could > just as well contain the path in the payload. > > There are options as to how to do that precisely (just the URI > reference in text form, or a RFC6690 link, or a CBOR list of path > segments, or a CRI reference[4] -- if the latter were in WGLC already > I'd recommend it wholeheartedly), but either of them would stay more > true to the style of the other messages in that the earlier message > informs the path choice of the next ones. > > An upside of this would be that it allows better behavior in presence > of proxies (see later), even though it may be practical to not spec > that out in full here. (But the path would be open for further specs, > and they'd just need some setting down of paving stones). > > [4]: https://datatracker.ietf.org/doc/draft-ietf-core-href/ > > * (Bycatch of suggesting URIs): It may be worth mentioning that the > NON's source address can easily be spoofed. Thus, any device on the > network can trigger what the authenticator may think of as a > device-triggered reauthentication, and the device may think of as an > authenticator-triggered reauthentication (provided it works that way, > see below when reauthentication is mentioned again). > > Even sending full URIs in message 0 would be no worse than the current > source spoofing. > > Sending URI paths in message 0 would make this minimally better > because the attacker would need to guess (or observe from the network) > the CoAP server's path. > > * In 3.1 General flow, the message types are described in high detail. > CoAP can generally be used with different transports (some of which > don't even do NON/CON). Also, while I think it's reasonable to expect > that a CoAP implementation can deal with requests coming in as either > CON or NON, I'd expect that some don't offer all possible choices to > applications. (A very constrained device may only send NON requests, > or an implementation may decide autonomously whether to send > piggy-backed or not). > > Can you clarify as to what of this is meant to be normative and what > exemplary? > > My recommendation is to state that what is prescribed is the flow of > requests and responses (which is what CoAP provides to the next > layer), while notes on reliable transmission are recommendations for > CoAP-over-UDP/DTLS. A similar statement, which I like a lot, is > already in 3.2 on error handling. > > (I can serve examples of how subtle incompatibilities can develop but > go unnoticed, but I'd only go through that if this is all really > intended to be prescriptive). > > * The reuse of the empty token only works if the peers actually respond > with piggy-backed responses, so that's where enforcing the above rules > would give some benefit -- but at the cost of losing existing CoAP > implementations that make no guarantees as to how the response will be > sent as long as it's reliable. > > * Proxying: As it is right now, this protocol just barely works across > proxies, and only if they support CoAP-EAP explicitly. (And while it > may sound odd to even consider that, bear in mind that they are used > in a very similar way in RFC9031). > > While it's a bit open whether all CoAP-based protocols should > reasonably be expected to work across proxies or not, a remark (maybe > before 3.1?) that "If CoAP proxies are used between EAP peer and EAP > authenticator, they must be configured with knowledge of this > specification, or the operations will fail after step 0." > > * 3.2.2: The use of RST is rather unusual here, for the same reasons as > the prescriptive message types. > > A response of 5.03 (Service Unavailable) has roughly the same size, > is available independent of transport, and on most libraries *way* > easier to use, if they support sending an RST to a well-formed message > at all. > > (Furthermore, the sender of the 5.03 can encode an estimate of the > remaining unavailable time in the Max-Age option; not sure if that is > of any help here). > > * 3.3.1: "received with the ACK", "sends piggybacked response" are, > again, overly specific. "received in the last response" and "sends a > response" could work as replacements even if message types are > presecriptive. > > * 3.3.1: "after the maximum retransmission attempts, the CoAP client > will remove the state from its side". > > So the device that's being kicked from the network can delay its own > eviction for about a minute as long as it doesn't answer? > > * 3.3.2: Is reauthentication always triggered by the EAP peer, or can it > also be triggered by the authenticator? If the latter, will the > authenticator use /.well-known/a again, or POST something to the > resource from where it'd DELETE in 3.3.1? > > * cryptosuites: What's the upgrade model of that hardcoded list? As it > is now, it looks pretty static, so updates would be through updates of > this document. The obvious alternative is an IANA registry with > ranges, policies and the usual pros and cons. > > Then again, this is not the first nor last time AEAD algorithms with > their parametrization and hash functions are assigned aggregate > numbers (I-D.ietf-lake-edhoc comes to mind which has asymmetric algs > in the mix too; probably others as well); can we deduplicate this with > anything? (Possibly by bringing this up with COSE or OSCORE people). > > * OSCORE derivation: Is it cryptographically necessary to derive *both* > a master secret and a master salt through KDF? (Sounds like a > needless step to me, as both only go into KDF once more when the > actual OSCORE parameters are derived). I *guess* there's a good reason > why the MSK is not used as the OSCORE IKM right away and the CSO as > OSCORE master salt, but it'd help to have at list a comment here on > why that's needed. > > (It may be useful to compare this step to the HKDF steps in OSCORE; > their info element is always a 5-element array with a 4th "type" > element of "Key" or "IV"; other extractions might just hook in there > with different type values, maybe, and save everyone an extra handling > step). > > * OSCORE ID derivation: > > * Randomly assigned full-length ideas look like an odd choice. They > are excessively long (nonce length - 6 is 7 for the MTI > AES-CCM-16-64-128 and shorter for other current ones, but I doubt > that keeping the IV *short* is necessarily a design criterion for > future algorithms). > > What commonly happens here (eg. in the ACE-OSCORE profile, or in > EDHOC) is that each party picks a recipient ID out of its pool of > currently unused IDs. This makes for shorter keys, and allows the > client to be sure that no two peers use the same context. > > Any chance something like that can still make it in? > > * If the parties happen to be assigned the same sender ID, bad things > happen (identical key derivation, nonce reuse, nuclear meltdown). > > If the current pattern of KDF'ing IDs stands, this needs to be > prevented explicitly. > > * The derivations of "OSCORE RECIPIENT ID" and "OSCORE SENDER ID" are > confusing as they each need to happen on both sides, and the terms > will match on one and need to be opposite on the other. > > (I couldn't even easily find which is intended to be which). > > My suggestion is to derive "OSCORE EAP PEER SENDER ID" and "OSCORE > AUTHENTICATOR SENDER ID" instead. (Or preferably shorter strings). > > * Exmaples: Do you envision particular EAP protocols to be used in the > given examples? > > Best regards > Christian From nobody Fri Sep 3 13:38:08 2021 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0F33A2D82; Fri, 3 Sep 2021 13:37:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <163070146623.14888.4018556860273406033@ietfa.amsl.com> Date: Fri, 03 Sep 2021 13:37:46 -0700 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eap-noob-06.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2021 20:37:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Nimble out-of-band authentication for EAP (EAP-NOOB) Authors : Tuomas Aura Mohit Sethi Aleksi Peltonen Filename : draft-ietf-emu-eap-noob-06.txt Pages : 68 Date : 2021-09-03 Abstract: The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication, and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB message between the peer device and authentication server to authenticate the in-band key exchange. The device must have a non-network input or output interface, such as a display, microphone, speaker, or blinking light, which can send or receive dynamically generated messages of tens of bytes in length. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 3 13:38:15 2021 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0623A2D9C; Fri, 3 Sep 2021 13:38:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <163070148100.18439.10536442213646733942@ietfa.amsl.com> Date: Fri, 03 Sep 2021 13:38:01 -0700 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-20.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2021 20:38:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) Authors : John Preuß Mattsson Mohit Sethi Filename : draft-ietf-emu-eap-tls13-20.txt Pages : 36 Date : 2021-09-03 Abstract: The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-Transport Layer Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security, privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Sep 4 12:20:00 2021 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB753A0AD5; Sat, 4 Sep 2021 12:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 U-6znKewZ-zA; Sat, 4 Sep 2021 12:19:52 -0700 (PDT) Received: from mx01.puc.rediris.es (outbound6mad.lav.puc.rediris.es [130.206.19.150]) (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 62B773A0AD9; Sat, 4 Sep 2021 12:19:52 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx01.puc.rediris.es with ESMTP id 184JJcbR032616-184JJcbS032616; Sat, 4 Sep 2021 21:19:38 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 82A952030C; Sat, 4 Sep 2021 21:19:38 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WlfMlr63McIr; Sat, 4 Sep 2021 21:19:38 +0200 (CEST) Received: from [192.168.1.38] (99.red-83-45-12.dynamicip.rima-tde.net [83.45.12.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id A091320063; Sat, 4 Sep 2021 21:19:35 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <38B0BDE9-5B5C-4F77-B914-DFA98AB711B0@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_C12154EB-76FF-47D5-A37A-A093401737AF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Sat, 4 Sep 2021 21:19:35 +0200 In-Reply-To: Cc: Rafa Marin-Lopez , =?utf-8?Q?Christian_Ams=C3=BCss?= , Dan Garcia Carrillo , "ace@ietf.org" To: =?utf-8?Q?G=C3=B6ran_Selander?= , EMU WG References: <07cd0942-9ee0-b124-b3a7-649f262d7c9e@uniovi.es> <6d2a20fc-7b79-4555-840e-d57f686be42f@VE1EUR02FT003.eop-EUR02.prod.protection.outlook.com> X-Mailer: Apple Mail (2.3445.104.21) X-FEAS-SPF: spf-result=pass, ip=155.54.212.171, helo=xenon44.um.es, mailFrom=rafa@um.es Authentication-Results: mx01.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=rafa@um.es X-FE-Policy-ID: 2:15:0:SYSTEM, 2:15:1:uniovi.es DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=iK3C1DA8f+MdK2UyGrnecTFBf/LuuVwV2avuH5RoXcg=; b=Sj0jD7cCckU7HBNskMASR8YupqrVDX/fGUINtNJJ7UIR4eHAmuAF+75ngMW4NEOomB0lmHf9s8gh p5mzzXIPqsAz0kwXkGKG6jm6vVdwY8UXjOze/sr4Og75EhLeOnir/WMTti3zoigkP+qMLHe8LAJb Q+1DyMzxi/ZWQCHOg0FuKoBsVGMs3yJC0Zeu6cypx5cV5mKZ3gwP5E385Z72xg+fp4xG9Pf+V4Mz jcEkmFF2JQzzEh25M4C/eodI6En9H361MZD6+bK9Cx7Xgbq8t50ViC0iOEh89geP4nbowSHNqZ4R koFs9cv720qTMsPmVpzQwHuu0L4KyGVmrxZwfw== Archived-At: Subject: Re: [Emu] [Ace] About securing last exchange CoAP-EAP ( and EAP state machine - RFC 4137) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2021 19:19:59 -0000 --Apple-Mail=_C12154EB-76FF-47D5-A37A-A093401737AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi G=C3=B6ran: Thanks for your comments. Please see ours inline > El 26 ago 2021, a las 12:12, G=C3=B6ran Selander = escribi=C3=B3: >=20 > Hi, > =20 > Here is a late response to this thread (see first mail at the end). > =20 > =EF=BB=BFOn 2021-08-16, 16:52, "Ace on behalf of Christian Ams=C3=BCss" = on behalf of = christian@amsuess.com > wrote: > =20 > Hello, > =20 > On Sat, Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo = wrote: > > As such, CoAP server (left side) could not see the content of = the CoAP > > message (message 7) without deciphering it. Moreover, as the = URI-path is > > also ciphered we cannot point to the right application to = process the > > message to achieve an alternate indication of success. > =20 > If the recipient ID were available a bit earlier (and not derived = from > the MSK), would it then be viable to infer from the OSCORE ID that = this > is the last message, process an "EAP success", and start = derivation just > to extract the session lifetime (and thereby confirm the keys)? > =20 > (That'd be all assuming that the "EAP success" contains really = just the > EAP success code and no further information, which would be = "compressed" > into the "some OSCORE is sent on this" information, and that the > Session-Lifetime does not need to be known to advance the EAP = state > machine). > =20 > [GS] If I understand right, MSK is not intended to be available from = the EAP state machine until "EAP success" has been declared, > which creates a problem to protect the message carrying the "EAP = success" with MSK or key derived from it. Even if EAP success would only = be integrity protected, there is still need to access the key to verify = the integrity of the success message which is a catch 22. In reality, the problem is not protecting message 7 (in fact, the EAP = authenticator can protect it) but the EAP peer (CoAP server) is not able = to verify the protected message 7 with OSCORE.=20 To be more specific. The EAP state machine (RFC 4137), in particular, = the EAP peer state machine (Figure 3), defines two variables that = constitute part of the interface with the EAP lower-layer (which is = CoAP-EAP). One variable is eapKeyData and the other eapKeyAvailable. It = turns out that eapKeyData changes from NONE to the key value in state = METHOD when the EAP method exports a key, which means the MSK is set in = eapKeyData. However, only in the SUCCESS state, the eapKeyAvailable = variable is set to TRUE, indicating to the EAP lower-layer that there is = a key available. The SUCCESS state is reached when receiving, for = example, an EAP success or for example there is an indication of the EAP = lower-layer (altAccept). However, and here it is the problem, the EAP = peer needs the key to process/decrypt message 7 and the eapKeyAvailable = is FALSE because EAP peer state machine is not in SUCCESS state. Having said this, it seems that nothing precludes that an EAP = lower-layer can check the state of eapKeyData to see if eapKeyData !=3D = NONE and to access key even though eapKeyAvailable is still FALSE. In = fact, eapKeyAvailable is set TRUE when the SUCCESS state is reached by = verifying precisely if eapKeyData !=3D NONE. As an example, = wpa_supplicant has a function to recover this key: const u8 * eap_get_eapKeyData(struct eap_sm *sm, size_t *len) { if (sm =3D=3D NULL || sm->eapKeyData =3D=3D NULL) { *len =3D 0; return NULL; } *len =3D sm->eapKeyDataLen; return sm->eapKeyData; } which is checking if eapKeyData is not NULL (NONE) to return the key. = There is no other verification. And the function is well programmed = according to the RFC 4137, in our opinion. Therefore, the EAP lower-layer could access the MSK by looking at the = eapKeyData variable. If the EAP lower-layer accesses the eapKeyData, it = can create the OSCORE context with the single goal of decrypting message = 7 without the need of an opportunistic success. In fact, the state = machine is not yet moved to SUCCESS state when accessing eapKeyData. If = message 7 protected with OSCORE is verified correctly, it means the = counterpart (EAP authenticator) already has the MSK, and it could be = considered as AltAccept, which will move the EAP peer state machine to = the final state. If, for some reason (though we are not able to find out = one), the EAP peer ends up in the FAILURE state, the EAP peer can get = rid of the OSCORE context and report an error to the EAP authenticator. In this sense, we have a question for the EMU WG:=20 Would be a problem, taking into account RFC 4137, if an EAP lower-layer = access the eapKeyData value (if eapKeyData changes from NONE to a value) = for (only) decrypting information sent by the EAP authenticator before = reaching the SUCCESS state? Apparently, it would be for the definition = of eapKeyAvailable, although we do not see any impediment taking into = account the eapKeyData is exposed in the current EAP peer state machine. = If this option is considered an acceptable behavior, the problem is = solved.=20 > =20 > As far as I understand the two proposals (by the authors and by = Christian) they are both opportunistic: preliminary declare success, get = the MSK, derive the key, and attempt to verify the message. But it was = not clear to me if success can be "withdrawn" or what happens if the = message doesn't verify. In the option we described above, it would not be opportunistic because = there is no declaration of success until message 7 is processed = correctly (including OSCORE) > =20 > Or conversely, if success can be declared opportunistically before = access to MSK and without verification of message 7, then why not do = that already before reception of message 7, and withdraw if it doesn't = verify? I think that is not possible because that would move the EAP peer state = machine to a final state SUCCESS without any chance to withdraw.=20 > =20 > Other alternatives: > =20 > * If the mapping from EAP to CoAP client/server is instead reversed, = then message 8 would be a CoAP request which can be protected by OSCORE = using a key derived from MSK since it is by then available. This would = add a message 9 (10% of the total no. of messages) for key confirmation = in the other direction. If we change the role, the EAP responses go inside the CoAP requests = that complicates the design. Moreover, we have the reasons mentioned in = the I-D (section 5.3) > =20 > * Alternatively, OSCORE may be started after EAP is concluded. This = would add another message exchange but that exchange could be normal = traffic and thus not add to the number of messages, if key confirmation = can wait until there is traffic. An extra exchange for key confirmation = can be added only in use cases it can't wait and there is no traffic, = whatever those are. There is a similar setting in LAKE, where EDHOC has = an optional message 4 if explicit key confirmation cannot be obtained = otherwise. Yes, we have considered this case as well. As we see it, key = confirmation cannot wait. So it becomes mandatory. Without that step, = the EAP peer will not know the access has been granted. Therefore, under = CoAP-EAP standpoint, running OSCORE after EAP would be required (which = means that two additional messages are included in the design anyway). = It is true the exchange could be also used to send traffic. The = advantage of this approach is that OSCORE can be used and the design may = be more simple. The disadvantage is that we are adding two additional = messages, which is not good if we consider constrained links.=20 Btw, two other options would be also possible: 1) To add a new cryptosuite to OSCORE to support NULL encryption + = integrity=20 2) Or to create an authentication tag based on COSE but acting only at = payload level. We would achieve key confirmation in message 7 and 8 = without using OSCORE, and after that OSCORE core context can be created = safely for posterior exchanges. But under CoAP-EAP standpoint the = process has finished. We tend to think option 2), as Dan mentioned, would meet all we want : = access to the MSK as expected in the EAP state machine (SUCCESS state); = key confirmation; reducing the number of messages; and creating the = OSCORE context safely afterwards. The only =E2=80=9Cproblem=E2=80=9D we = see is that we are not using OSCORE in message 7 and 8 but COSE with = integrity for (only) the payload. Opinions? Best Regards. > =20 > =20 > G=C3=B6ran > =20 > =20 > =20 > =20 > From: Ace > on = behalf of Dan Garcia Carrillo > > Date: Saturday, 14 August 2021 at 13:37 > To: EMU WG >, "ace@ietf.org = " > > Cc: "garciadan@uniovi.es " = > > Subject: [Ace] About securing last exchange CoAP-EAP > =20 > Dear ACE and EMU WG members, > =20 > In the last exchange of CoAP-EAP we intended to run OSCORE to achieve = key confirmation, a protected EAP success and the establishment of the = OSCORE security association. It was our understanding that only = integrity protection was possible but it is not the case after = consulting OSCORE authors. More specifically, the payload and URI-Path = with OSCORE are class E they are ciphered (and integrity protected) and, = as far as we understand, there is no option, currently, of using a NULL = encryption suite to achieve only integrity.=20 > =20 > CoAP CoAP > Sever Client > ... > 5) |<----------------------------------------| > | ACK [0x9869] | > | Token (0xac) | > | 2.01 Created Location-Path [/a/z] | MSK > | Payload EAP-X-Resp (n) | | > 6) |---------------------------------------->| v > | CON [0x7811] POST /a/z |OSCORE > | Token (0xac), OSCORE |CONTEXT > MSK | Payload (EAP success||Session-Lifetime) |(*) > | 7) |<----------------------------------------| > v | ACK [0x7811] | > OSCORE (*)| Token (0xac), OSCORE | > CONTEXT 8) |---------------------------------------->| > (*) Protected with OSCORE > =20 > As such, CoAP server (left side) could not see the content of the CoAP = message (message 7) without deciphering it. Moreover, as the URI-path is = also ciphered we cannot point to the right application to process the = message to achieve an alternate indication of success. However, the MSK = required to create the OSCORE context, which allows deciphering the = message, is not available yet (even though eapKeyData variable has = content). The reason is that, according to EAP state machine (RFC 4137) = Figure 3, the MSK becomes available (eapKeyAvailable =3D TRUE) when EAP = success (rxSuccess or altSuccess from the EAP lower layer) is sent to = EAP state machine. > =20 > rxSuccess && > (reqId =3D=3D lastId) && > (decision !=3D FAIL) =20 > | > V > __________________________ > |______SUCCESS_____________| > |if (eapKeyData !=3D NONE) | > | eapKeyAvailable =3D TRUE | > |eapSuccess =3D TRUE | > |__________________________| > ^ > | > (altAccept && decision !=3D FAIL) || > (idleWhile =3D=3D 0 && > decision =3D=3D UNCOND_SUCC) > =20 > Our proposed solution is to generate an authentication tag in the form = of a COSE object that will be used to integrity-protect the payload of = message 7 and message 8, allowing the EAP peer to see the EAP success = and sending it to the EAP state machine so that, after obtaining the = MSK, verifying the authentication tag in message 7 (key confirmation). = After message 7 is processed correctly, CoAP server will be able to = generate the OSCORE security context and after processing message 8 CoAP = client (right entity in the exchange) will create the OSCORE context. = =46rom this point CoAP messages between both entities can be protected = using OSCORE context. > =20 > CoAP CoAP > Sever Client > 5) |<----------------------------------------| > | ACK [0x9869] | > | Token (0xac) | > | 2.01 Created Location-Path [/a/z] | > | Payload EAP-X-Resp (n) | > 6) |---------------------------------------->| > | CON [0x7811] POST /a/z | > | Token (0xac) | MSK > | Payload (EAP success||Session-Lifetime | | | > MSK | || AuthenticationTag) | v | > | | 7) |<----------------------------------------|AUTH_KEY| > | v | ACK [0x7811] | | > |AUTH_KEY | 2.01 Created Location-Path [/a/z1] | | > v | Token (0xac) | | > OSCORE Context| Payload(AuthenticationTag) | V > 8) |---------------------------------------->| OSCORE > Context > =20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace = -------------------------------------------------------=20 Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_C12154EB-76FF-47D5-A37A-A093401737AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi G=C3=B6ran:

Thanks for your comments. Please see = ours inline

El 26 ago 2021, a las 12:12, G=C3=B6ran = Selander <goran.selander=3D40ericsson.com@dmarc.ietf.org> = escribi=C3=B3:

Hi,
 
Here is a late response to this thread (see first = mail at the end).
 
=EF=BB=BFOn 2021-08-16, 16:52, = "Ace on behalf of Christian Ams=C3=BCss" <ace-bounces@ietf.org on behalf of christian@amsuess.com> wrote:
 
    Hello,
 
    On Sat, = Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo wrote:
    > As = such, CoAP server (left side) could not see the content of the CoAP
    > = message (message 7) without deciphering it. Moreover, as the URI-path = is
    > also = ciphered we cannot point to the right application to process the
    > = message to achieve an alternate indication of success.
 
    If the = recipient ID were available a bit earlier (and not derived from
    the MSK), = would it then be viable to infer from the OSCORE ID that this
    is the = last message, process an "EAP success", and start derivation just
    to extract = the session lifetime (and thereby confirm the keys)?
 
    (That'd be = all assuming that the "EAP success" contains really just the
    EAP = success code and no further information, which would be "compressed"
    into the = "some OSCORE is sent on this" information, and that the
    = Session-Lifetime does not need to be known to advance the EAP state
    = machine).
 
[GS] If I = understand right, MSK is not intended to be available from the EAP state = machine until "EAP success" has been = declared,
which creates a problem to protect the message = carrying the "EAP success" with MSK or key derived from it. Even if EAP = success would only be integrity protected, there is still need to access = the key to verify the integrity of the success message which is a catch = 22.

In= reality, the problem is not protecting message 7 (in fact, the EAP = authenticator can protect it) but the EAP peer (CoAP server) is not able = to verify the protected message 7 with OSCORE. 

To be more specific. The = EAP state machine (RFC 4137), in particular, the EAP peer state machine = (Figure 3), defines two variables that constitute part of the interface = with the EAP lower-layer (which is CoAP-EAP). One variable = is eapKeyData and the other eapKeyAvailable. It turns out that eapKeyData changes = from NONE to the key value in state METHOD when the EAP method exports a = key, which means the MSK is set in eapKeyData. However, only in the = SUCCESS state, the eapKeyAvailable variable is set to TRUE, indicating = to the EAP lower-layer that there is a key available. The SUCCESS state = is reached when receiving, for example, an EAP success or for example = there is an indication of the EAP  lower-layer (altAccept). = However, and here it is the problem, the EAP peer needs the key to = process/decrypt message 7 and the eapKeyAvailable is FALSE because EAP = peer state machine is not in SUCCESS state.

Having said this, it = seems that nothing precludes that an EAP lower-layer can check the state = of eapKeyData to see if eapKeyData !=3D NONE and to access key even = though eapKeyAvailable is still FALSE. In fact, eapKeyAvailable is set = TRUE when the SUCCESS state is reached by verifying precisely if = eapKeyData !=3D NONE. As an example, wpa_supplicant has a function to recover this = key:

const u8 * = eap_get_eapKeyData(struct eap_sm *sm, size_t *len)
{
if (sm =3D=3D NULL || sm->eapKeyData =3D=3D NULL) = {
= *len =3D 0;
return NULL;
= }

*len =3D = sm->eapKeyDataLen;
return = sm->eapKeyData;
}

which= is checking if eapKeyData is not NULL (NONE) to return the key. There = is no other verification. And the function is well programmed according = to the RFC 4137, in our opinion.

Therefore, the EAP = lower-layer could access the MSK by looking at the eapKeyData variable. = If the EAP lower-layer accesses the eapKeyData, it can create the OSCORE = context with the single goal of decrypting message 7 without the need of = an opportunistic success. In fact, the state machine is not yet moved to = SUCCESS state when accessing eapKeyData. If = message 7 protected with OSCORE is verified correctly, it means the = counterpart (EAP authenticator) already has the MSK, and it could be = considered as AltAccept, which will move the EAP peer state machine to = the final state. If, for some reason (though we are not able to = find out one), the EAP peer ends up in the FAILURE state, the EAP peer = can get rid of the OSCORE context and report an error to the EAP = authenticator.

In = this sense, we have a question for the EMU = WG

Would be a problem, taking into account RFC 4137, if an EAP = lower-layer access the eapKeyData value (if eapKeyData changes from NONE = to a value) for (only) decrypting information sent by the EAP = authenticator before reaching the SUCCESS state? Apparently, it would be = for the definition of eapKeyAvailable, although we do not see any = impediment taking into account the eapKeyData is exposed in the current = EAP peer state machine. If this option is considered an = acceptable behavior, the problem is = solved

 
As far as I = understand the two proposals (by the authors and by Christian) they are = both opportunistic: preliminary declare success, get the MSK, derive the = key, and attempt to verify the message. But it was not clear to me if = success can be "withdrawn" or what happens if the message doesn't = verify.

In = the option we described above, it would not be opportunistic because = there is no declaration of success until message 7 is processed = correctly (including OSCORE)
 
Or conversely, if success can be declared = opportunistically before access to MSK and without verification of = message 7, then why not do that already before reception of message 7, = and withdraw if it doesn't = verify?

I think that is not possible because that would = move the EAP peer state machine to a final state SUCCESS without any = chance to withdraw. 

 
Other alternatives:
 
* If the = mapping from EAP to CoAP client/server is instead reversed, then message = 8 would be a CoAP request which can be protected by OSCORE using a key = derived from MSK since it is by then available. This would add a message = 9 (10% of the total no. of messages) for key confirmation in the other = direction.

If we change the role, the EAP responses go inside = the CoAP requests that complicates the design. Moreover, we have the = reasons mentioned in the I-D (section 5.3)

 
* = Alternatively, OSCORE may be started after EAP is concluded. This would = add another message exchange but that exchange could be normal traffic = and thus not add to the number of messages, if key confirmation can wait = until there is traffic. An extra exchange for key confirmation can be = added only in use cases it can't wait and there is no traffic, whatever = those are. There is a similar setting in LAKE, where EDHOC has an = optional message 4 if explicit key confirmation cannot be obtained = otherwise.

Yes, we have considered this case as well. As we = see it, key confirmation cannot wait. So it becomes mandatory. Without = that step, the EAP peer will not know the access has been granted. = Therefore, under CoAP-EAP standpoint, running OSCORE after EAP would be = required (which means that two additional messages are included in the = design anyway). It is true the exchange could be also used to send = traffic. The advantage of this approach is that OSCORE can be used and = the design may be more simple. The disadvantage is that we are adding = two additional messages, which is not good if we consider constrained = links. 

Btw, two other options = would be also possible:

1) To add a = new cryptosuite to OSCORE to support NULL encryption + = integrity 
2) Or to create an authentication tag based on = COSE but acting only at payload level. We would achieve key confirmation = in message 7 and 8 without using OSCORE, and after that OSCORE core = context can be created safely for posterior exchanges. But under = CoAP-EAP standpoint the process has finished.

We tend to think option 2), as Dan mentioned, = would meet all we want : access to the MSK as expected in the EAP state = machine (SUCCESS state); key confirmation; reducing the number of = messages; and creating the OSCORE context safely afterwards. The only = =E2=80=9Cproblem=E2=80=9D we see is that we are not using OSCORE in = message 7 and 8 but COSE with integrity for (only) the payload. = Opinions?

Best Regards.

 
 
G=C3=B6ran
 
 
 
 
From: Ace <ace-bounces@ietf.org> on behalf of Dan Garcia Carrillo = <garciadan@uniovi.es>
Date: Saturday, 14 August = 2021 at 13:37
Subject: [Ace] About securing = last exchange CoAP-EAP
 
Dear ACE and EMU WG = members,
 
In the last exchange of = CoAP-EAP we intended to run OSCORE to achieve key confirmation, a = protected EAP success and the establishment of the OSCORE security = association. It was our understanding that only integrity protection was = possible but it is not the case after consulting OSCORE authors. More = specifically, the payload and URI-Path with OSCORE are class E they are = ciphered (and integrity protected) and, as far as we understand, there = is no option, currently, of using a NULL encryption suite to achieve = only integrity. 
 
          &nb= sp;  = CoAP           &nbs= p;            =              = CoAP
          &nb= sp; Sever          =             &n= bsp;           &nbs= p; Client
          &nb= sp;            = ;        ...
           = 5) |<----------------------------------------|
          &nb= sp;   | ACK = [0x9869]           =             &n= bsp;    |
          &nb= sp;   | Token = (0xac)           &n= bsp;           &nbs= p;    |
          &nb= sp;   | 2.01 Created Location-Path = [/a/z]       | MSK
          &nb= sp;   | Payload EAP-X-Resp = (n)            = ;      |  |
           = 6) |---------------------------------------->|  v
          &nb= sp;   = |            &= nbsp;   CON [0x7811] POST /a/z   |OSCORE
          &nb= sp;   = |            &= nbsp;     Token (0xac), OSCORE   = |CONTEXT
    = MSK       | Payload (EAP = success||Session-Lifetime) |(*)
     |     7) = |<----------------------------------------|
     = v        | ACK = [0x7811]           =             &n= bsp;    |
   OSCORE  (*)| Token (0xac), = OSCORE           &n= bsp;        |
   CONTEXT 8) = |---------------------------------------->|
          &nb= sp;   (*) Protected with OSCORE
 
As such, CoAP server (left = side) could not see the content of the CoAP message (message 7) without = deciphering it. Moreover, as the URI-path is also ciphered we cannot = point to the right application to process the message to achieve an = alternate indication of success. However, the MSK required to create the = OSCORE context, which allows deciphering the message, is not available = yet (even though eapKeyData variable has content). The reason is that, = according to EAP state machine (RFC 4137) Figure 3, the MSK becomes = available (eapKeyAvailable =3D TRUE) when EAP success (rxSuccess or = altSuccess from the EAP lower layer) is sent to EAP state machine.
 
rxSuccess &&
    (reqId = =3D=3D lastId) &&
    (decision !=3D = FAIL)   
          &nb= sp;  |
          &nb= sp;  V
__________________________
|______SUCCESS_____________|
|if (eapKeyData !=3D = NONE)   |
|   eapKeyAvailable =3D TRUE |
|eapSuccess =3D = TRUE         |
|__________________________|
          &nb= sp;  ^
          &nb= sp;  |
(altAccept && = decision !=3D FAIL) ||
    (idleWhile =3D=3D 0 &&
     decision =3D=3D = UNCOND_SUCC)
 
Our proposed solution is to = generate an authentication tag in the form of a COSE object that will be = used to integrity-protect the payload of message 7 and message 8, = allowing the EAP peer to see the EAP success and sending it to the EAP = state machine so that, after obtaining the MSK, verifying the = authentication tag in message 7 (key confirmation). After message 7 is = processed correctly, CoAP server will be able to generate the OSCORE = security context and after processing message 8 CoAP client (right = entity in the exchange) will create the OSCORE context. =46rom this = point CoAP messages between both entities can be protected using OSCORE = context.
 
          &nb= sp;  = CoAP           &nbs= p;            =              = CoAP
          &nb= sp; Sever          =              =             &n= bsp;Client
           = 5) |<----------------------------------------|
          &nb= sp;   | ACK = [0x9869]           =             &n= bsp;    |
          &nb= sp;   | Token = (0xac)           &n= bsp;           &nbs= p;    |
          &nb= sp;   | 2.01 Created Location-Path = [/a/z]       |
          &nb= sp;   | Payload EAP-X-Resp = (n)            = ;      |
           = 6) |---------------------------------------->|
          &nb= sp;   = |            &= nbsp;   CON [0x7811] POST /a/z   |
          &nb= sp;   = |            &= nbsp;           &nb= sp; Token (0xac)   |      MSK
          &nb= sp;   | Payload (EAP success||Session-Lifetime  = |     |  |
  MSK         = |           || = AuthenticationTag)         = |     v  |
  | |      7) = |<----------------------------------------|AUTH_KEY|
  | = v         | ACK = [0x7811]           =             &n= bsp;    |        |
  |AUTH_KEY   | 2.01 Created = Location-Path [/a/z1]      = |        |
  = v           | Token = (0xac)           &n= bsp;           &nbs= p;    |        |
OSCORE Context| = Payload(AuthenticationTag)        =       = |        V
           = 8) = |---------------------------------------->|    &nbs= p; OSCORE
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;   Context
 
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

-------------------------------------------------------&nb= sp;
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 Murcia - = Spain
Telf: +34868888501 Fax: +34868884151 e-mail: = rafa@um.es
-------------------------------------------------= ------

= --Apple-Mail=_C12154EB-76FF-47D5-A37A-A093401737AF-- From nobody Mon Sep 6 11:20:15 2021 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A11AC3A193C; Mon, 6 Sep 2021 11:20:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk CC: Joseph Salowey , draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org, joe@salowey.net, rdd@cert.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <163095240489.32587.6236015358932093639@ietfa.amsl.com> Date: Mon, 06 Sep 2021 11:20:05 -0700 Archived-At: Subject: [Emu] Last Call: (Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)) to Proposed Standard X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 18:20:06 -0000 The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-09-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-Transport Layer Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security, privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Sep 6 11:26:04 2021 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8639F3A1983; Mon, 6 Sep 2021 11:26:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-emu-eap-noob@ietf.org, emu-chairs@ietf.org, emu@ietf.org, joe@salowey.net, rdd@cert.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <163095276252.10909.14792174468802097434@ietfa.amsl.com> Date: Mon, 06 Sep 2021 11:26:02 -0700 Archived-At: Subject: [Emu] Protocol Action: 'Nimble out-of-band authentication for EAP (EAP-NOOB)' to Proposed Standard (draft-ietf-emu-eap-noob-06.txt) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 18:26:03 -0000 The IESG has approved the following document: - 'Nimble out-of-band authentication for EAP (EAP-NOOB)' (draft-ietf-emu-eap-noob-06.txt) as Proposed Standard This document is the product of the EAP Method Update Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ Technical Summary The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB message between the peer device and authentication server to authenticate the in-band key exchange. The device must have an input or output interface, such as a display, microphone, speaker or blinking light, which can send or receive dynamically generated messages of tens of bytes in length. Working Group Summary The document received a detailed early IoT directorate review. Document Quality At least three public implementations of the protocol are available: 1. wpa_supplicant - https://github.com/tuomaura/eap-noob 2. contiki - https://github.com/eduingles/coap-eap-noob 3. hostap - https://github.com/Vogeltak/hostap The protocol has security proofs: 1. Proverif: https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/proverif 2. mcrl2: https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/mcrl2 Personnel Document Shepherd - Joe Salowey Responsible AD - Roman Danyliw From nobody Fri Sep 10 01:47:16 2021 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16F3A08D9; Fri, 10 Sep 2021 01:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, 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 (1024-bit key) header.d=unioviedo.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 W1zMD7GDRRjA; Fri, 10 Sep 2021 01:43:17 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20602.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::602]) (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 3C0DC3A08DB; Fri, 10 Sep 2021 01:43:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nZ5ly43ahfSRV9fiehMZHPAIkHyyh7jhof/iTHydAzupjzAN5Ly9qRo+OgqyOhMiw4pesPnnwa5kmFikKdPEOGX7POearyKG+8WSwsj1hV0jlcycc9bHC1PRkKlmOs0FOb+6UBxBdG90qZrzOLf1TkwHUvY/LOOke3HeSePVCVPJkNwUSj0G4iHMazNb6/IWiSqUPRwiwJfmNeqq8YwOx1p+u3eCuRs2GhQuW8N2ZLMBdhtdJ3lu75FNn3m5Lrc8KLNovHpE2wb6HzOXJu1WCeZSXz8mCa//VFlQAB9IOGbiS5aNPby5cv8wG32b/brPL81/Hwu1tsoYdY7AXBH1HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eNP+WTYA4cyB4aNcBTBXUc0mqd8lMkX/TFye+K4j4Ek=; b=UUjNw9B2pskF9u5UursHVtgyXNMI/h9eVCyIXt71YXBhFloWgPAIl7FFlAoyBmrN4L230r/fMB8lPXr3MI4d+e7hosb3brN5sn6HmfjycfJwhS9rF27YdiFu/SJ+yoCXvLW0H8Kq8DqGX1Ttt0PtrP2XSILPgdFORgcve3q077Fkzk2V0QpJDXC7maI7ziGr77Tv0tpVcxP+tf6GS0dfar8R3f7TFd6rDmq9PHOqsC8/cE3nNov9SrWlyBrcswGWhi2iGyeJJK8wJmQZJ9OiNTYycX0Txcf5jOEGlGr7yE028OOlMMFlIysxMTzcy4zoJ0iwYvIHmm5dc2OeaM1y5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eNP+WTYA4cyB4aNcBTBXUc0mqd8lMkX/TFye+K4j4Ek=; b=hJ+t1Ip6QlkaS7KG8eFPJ0cqlRGInyDUwxYMPr58IqNkHCilXRFGHuTFxA7r16TuMowGzhmEueoWZN1ieq/MFQL3Xy1BDlaP7dW7CcnCjcF/Rf107oecKzvt0xuYtzweLKvCFvzMtCWMkSEfzq2Kg9bSgvC9/yalmiIMhOUeEH0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=uniovi.es; Received: from DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) by DBBPR08MB5994.eurprd08.prod.outlook.com (2603:10a6:10:20d::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.22; Fri, 10 Sep 2021 08:43:01 +0000 Received: from DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::70e4:c7c8:b279:2395]) by DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::70e4:c7c8:b279:2395%7]) with mapi id 15.20.4500.017; Fri, 10 Sep 2021 08:43:01 +0000 Cc: garciadan@uniovi.es, EMU WG , "ace@ietf.org" , Rafa Marin-Lopez , core@ietf.org To: =?UTF-8?Q?Christian_Ams=c3=bcss?= References: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es> From: Dan Garcia Carrillo Message-ID: Date: Fri, 10 Sep 2021 10:42:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7CFFD4FA37F207B354D8AA67" Content-Language: es-ES X-ClientProxiedBy: MR1P264CA0098.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:50::8) To DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [156.35.171.42] (156.35.171.42) by MR1P264CA0098.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:50::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Fri, 10 Sep 2021 08:42:58 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8a117da7-b858-4fcf-1b9c-08d97436feeb X-MS-TrafficTypeDiagnostic: DBBPR08MB5994: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: l5sQOLkZvhgqMXt1dxfE1TzuxxSOJJ/Npj6FucUBX1wwk8Yf4G45nDZ8TylyBApB8svhjQto7y61y8pqUaMeYrm8Tw1DuhgQIXZouJ2sC6MB72/w2y6DLiKqXxEZ13xDyl2KypPvvG6s7WYjoI5aPHxhCiFmsobVsjCNxDJ1II496oCf7qvBSu8RjjK4zkFpbBCmthH/1KEAY1CtKk4xE/5+fMlimSGHVIp5SfbGDZEZmENrLpsVMhyvXvsK39B401kmwsH6jMSpx02Ci9h7e/gU2BJMu16/6FPXjZ4/odhTem/smN5Ma8I2eUMBqC0xAadMFx4zLckWkess9pkOcnxJ4z2HSM/49TY6ZHUek3twpYEbgNfZ8IEurk5D9aN1ilOXHB+JcQEkpTkigBnzQiWyU8HL9Ms21nHvtjZ+KKCKCkcZTk494xGRTv27O6QqnzEIn0gJZXrci2bpV9SWk7snVaTxD+G2wrLTv7K3dcCGYSeXp3Zn/xLabcAfyUABAWHuIqZltgDDU31GK5ECIxynP+n0LjQ27CkpSdonvck0DePY0w1K8u3ULoye4Hp1Bg0cntmBD64OdXjwcsrR1FilZXtet1qNOaKpSu4Rsnw10oEribBETQri/TuNa2Wv7sVA3dEJn1puevt4wGXiRVGm91sAhEAUpGHuA9EmtkLPJo74UZlw7qM9P+m5mEPKclJEYjZTSvvpdDO04s9miDUVJ4nYqQG4C+ysII+MCKbQynm3q0hJsbU5fT0atvQ4wf1lol3XWszYwaS/S+ChjRZ6k9CJURX9cCKtbOd2c0+2pLIYyDbqNoulq02BGXdEcCgfM3lFL/Y8kv2RLxoKQb97/OGgeFqhDzi+qb3pHMFNcRAq85czNFrlRg4S97IoCFSo+fmEd/ViKyHE1vatcA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB6202.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(396003)(346002)(366004)(376002)(66574015)(31696002)(83380400001)(52116002)(54906003)(166002)(66556008)(16576012)(36756003)(31686004)(316002)(8936002)(2616005)(66946007)(4326008)(2906002)(956004)(6706004)(38350700002)(66476007)(30864003)(26005)(966005)(6486002)(53546011)(86362001)(8676002)(186003)(33964004)(478600001)(5660300002)(6916009)(38100700002)(429304003)(3940600001)(45980500001)(43740500002)(559001)(579004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?czg0YnFMVTk0VHEweFE5R0NxV3RQTlc5Mjg5VkxDRG5POHBvUmlYUnBqV3J0?= =?utf-8?B?VHNLdmVGY2ttV3VpL0diWEtqKzFrK0dFakZ0MnUzaXBBRzFsUjZ0WEl1MjVo?= =?utf-8?B?VHZGS2xCREliSy9ua0J1MzBNbUlHTzRTdjk4NzBhRm9ieGtFU1I5bVRLOUg5?= =?utf-8?B?MmlFM3BBQldGUnBib1gxcktKNlFoWmNlZ056dnNaandjNU9DQ1BUVXV6NWZL?= =?utf-8?B?bUxBcU14ZTJZQ3lpdVVEZEM1ZC9iR3RiditYYzdFNVVSSXFNLy9NQWZ6WDA2?= =?utf-8?B?YkVmOS9IemNNMVZDVjF4d0NVa3VUQTllVExnaVVmbmQ2RGpWdTlqVS9lUE8v?= =?utf-8?B?dzE0NENiS0ZxbWpoOHhYU0FpbndNaHR5NzJ1a29reGZzcVEzaEZHY1lnTjAr?= =?utf-8?B?TmxqSFlGSUFxYWlLeE9nUXNrb2NWc2ppd09hN3Q3L3gyMnBKaU52UU5acVNm?= =?utf-8?B?THRoSVV5M2k5WTRjM2J6WllsRVJBZGVWLytzVkZtSkt4UEViQzA0RlRaaFpG?= =?utf-8?B?V3V3OGlNdFdnZ050WTdhYjZEVWxpV3JxNTNzb3pxenJ6WlpMWVMwNFIxUjRF?= =?utf-8?B?ZUR4SU52V0UrSDFxaVVmYlFWV0JLTGJXdGpZdHoyL01Lc1Jpa2d5Mm9lTEZi?= =?utf-8?B?bFMwSW1Fd0xEK1V6QllKazZ3VzVqdVo1R3F1eVl0V0hRZ20vY1dCT1V6bEYv?= =?utf-8?B?WXlmTXNkczFDeXV4bC81ZjlEalYwV3lZR1g2dVViV2dsOXk1L05Ma2x3ekx5?= =?utf-8?B?ZlRQaGwzQVljS2pKM0xNajhSRXE1Vk9KSUZvWmY0VGs4UzlXY0x0dW4zSEkx?= =?utf-8?B?VjNLcDFLV3h4cXR6TCtPTG9IRHQ1NVFpeEtOMTJ5SGllcG85L1Z0Y1FTUGcv?= =?utf-8?B?WWJFblExTVBLYmllcEZvYkJGaTl4dG9CamZPeTNnSnF3bVFUcG1mWENhNzZr?= =?utf-8?B?RDVXdVpBT3A5MUFnSnhrWVhiQ3hkV2RQOEdabXF1MzU3V1lpRU01b1BvR1dI?= =?utf-8?B?cDNwV1h5N05ONVNNUE90L2tDWC8xWXFyQ3lHMUwzZXJBcnJqWUMxS09IRmhN?= =?utf-8?B?cXljTXhoNS9YdXFhS1BmUU1YQ2hWN3JWYTdFaXk0aHp3bzhaWXlJZVpwTGlt?= =?utf-8?B?Smp3MVo2SVk5NGtobnpxTzUydi9EZzVTMVp6QTU1OEMwMkxuUmsyQmJGKzE0?= =?utf-8?B?cnpIMUhPanpsUmtSWThTenZld0xrUjdULzdrQk9DNE1uUFVTaDM5d2huNmlJ?= =?utf-8?B?dERHbHM0UkZYSENoU1RkQTIwK0VSMUk2MEZRVDRJWHAxREZkbElBcVdnQWRy?= =?utf-8?B?OGJNUGVaay9aWGd5TmNVZERYL05kaWRQYjg3NWxKcm1MVVEyU29TemVRRXdo?= =?utf-8?B?dW1EMkpjSFdmeEdJc3F5VWFoQUpJL2tVbWZNV3AyZlBya2VIYm5GYy9UR1dm?= =?utf-8?B?KzVOR1BORFRNRU5NTlJVME8xdVJmemxRcUVlcEdSNUFzVi8yeEluR2Z4Yy80?= =?utf-8?B?YlRPWTFMU3MzWmoyRktQL052MVZpVlpENWpJM0JUOG9FV2FmK1dwWUNnZ0Zl?= =?utf-8?B?cS9mY1RMN29mdUtHL1RoMnZDTSs2QzgyaWZoTW5IeHZsQTdVcytMSGVJQUxh?= =?utf-8?B?cTNtR2pWWEpSaHZsS3JaYXM3c2o1NUlwTGNNSlkvaDFSbmkxUnhoY3VYeTA0?= =?utf-8?B?MEplYmJ3eVRQVnRUQS93a3dKemNyYnFqOVhub3plMS83bjRGNUhhTW42WGtW?= =?utf-8?Q?Kuhf8znaSX6+b97sxKF9E0M+ejzb97r6nqSKZ6r?= X-OriginatorOrg: uniovi.es X-MS-Exchange-CrossTenant-Network-Message-Id: 8a117da7-b858-4fcf-1b9c-08d97436feeb X-MS-Exchange-CrossTenant-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2021 08:43:01.3568 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Rev8OPvQdgUiceDoUx0CoduX9GRhWOE4x9rIHifRMRGRRzKPBaE57YggE1jsXhSJT9YbKXMr72agGkbV3zNFOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5994 X-MS-Exchange-CrossPremises-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 06 X-MS-Exchange-CrossPremises-Mapi-Admin-Submission: X-MS-Exchange-CrossPremises-MessageSource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 156.35.171.42 X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: DBBPR08MB5994.eurprd08.prod.outlook.com Archived-At: X-Mailman-Approved-At: Fri, 10 Sep 2021 01:47:14 -0700 Subject: Re: [Emu] [Ace] CoAP-EAP draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 08:43:24 -0000 --------------7CFFD4FA37F207B354D8AA67 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Christian, Thank you very much for your detailed revision, Please see inline our comments. > On 16/8/21 16:40, Christian Amsüss wrote: >> Hello CoAP-EAP authors and involved groups, >> (CC'ing core@ as this is a review on CoAP usage), >> >> >> I've read the -03 draft and accumulated a few comments; largely in >> sequence of occurrence. >> >> Over all, the protocol has improved a lot since I've last had my eyes on >> it. Several comments below are about how prescriptive the message types >> are. I believe that this should be resolved towards generality, or else >> the usability of this protocol with generic CoAP components will be >> limited (or, worse, still implemented and then surprisingly >> incompatible). >> >> >> * Figure 1: For readers new to the topic of EAP, I think that it might >>    be useful to extend this to cover also the EAP server or AAA >>    infrastructure, if that can be covered without too much complication. >> >>    Suggestion (without illusions of correctness): >> >>             IoT device            Controller >>           +------------+        +------------+ >>           | EAP peer/  |        | EAP auth./ |+-----+[ AAA infra. ] >>           | CoAP server|+------+| CoAP client|+-----+[ EAP server?] >>           +------------+  CoAP  +------------+  EAP? >>                    \_____ Scope of this document _____/ >> >>                        Figure 1: CoAP-EAP Architecture >> [Authors] This is a good point. We did not include it at first, as having a AAA infrastructure is not mandatory. But the optionality can also be expressed in the figure. We will consider using this for the next version. Please also be aware that this architecture including AAA is assuming something called EAP authenticator in pass-through mode. Nevertheless, an EAP authenticator in standalone mode is also possible, where no AAA exists. >> * `/.well-known/a`: [note: May be irrelevant, see next two items] >> >>    If the designated experts don't go along with a >>    very-short option (I'd kind of doubt you'd get anything shorter than >>    `/.well-known/eap`) and if that puts you up against practical limits, >>    using a short-hand option might be viable. >> >>    So far there's no document for it and I've only pitched the idea >>    briefly at an interim[1] (slides at [2]), but if push comes to shove >>    and you need the compactness, let me know and that work can be >>    expedited. >> >>    [1]: >> https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core >>    [2]: >> https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/slides-interim-2021-core-05-sessa-core-option-for-well-known-resources-00 [Authors] You are correct. This was addressed by the well-known URI experts and they have proposed to use /.well-known/coap-eap >> >> * Discovering the Controller is described rather generically, but with >>    CoAP discovery as an example. >> >>    As long as CoAP discovery (as per RFC6690/7252) is used, that already >>    produces a URI, which can contain any path the server picked. It has >>    thus no need for a well-known path. >> >>    Are there other discovery options envisioned that'd only result in a >>    network address? Only for these, a well-known path would make sense. >>    (And then it's up to the envisioned client complexity if one is >>    warranted). >> [Authors] This is related to the next point. As long as the IoT device sends the resource for the authentication in this case we would remove the need for the well-known in the IoT device. >>    For comparison, RD[3] explores some of the options. A path may be >>    discovered using CoAP discovery as `?rt=core.rd*` right away from >>    multicast. Or an address may be discovered using an IPv6 RA option, >>    with CoAP discovery acting on that address. Only for cases of very >>    simple endpoints, it also defines a `/.well-known/rd` name that >> can be >>    used without CoAP discovery (and thus link parsing) happening >>    beforehand. The same rationales may apply for EAP (the devices using >>    the resource are mostly servers, otherwise, and send a very simple >>    request to start things), but again that's only if the address was >>    discovered through something that's not CoAP discovery already. >> >>    [3]: >> https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-rd-discovery-and-other-inte >> [Authors] This is a good point. We may need to add a discussion of how the service can be discovered since, as you commented, there are different ways to do so. Our initial idea was to contact directly with the Border Router, which is consistent with what you comment about receiving the IPv6 RA to receive the IPv6 Address. Hence the communication would be directly using the /.well-known URI and the discovered IPv6 address. >> * For message 1, why does this need to go to a fixed resource? There has >>    been previous communication in message 0 in which the resource could >>    have been transported. >> >>    Granted, it's not as easy as in messages 2-to-3 etc where the >>    Location-* options are around, but the original message 0 POST could >>    just as well contain the path in the payload. >> >>    There are options as to how to do that precisely (just the URI >>    reference in text form, or a RFC6690 link, or a CBOR list of path >>    segments, or a CRI reference[4] -- if the latter were in WGLC already >>    I'd recommend it wholeheartedly), but either of them would stay more >>    true to the style of the other messages in that the earlier message >>    informs the path choice of the next ones. >> >>    An upside of this would be that it allows better behavior in presence >>    of proxies (see later), even though it may be practical to not spec >>    that out in full here. (But the path would be open for further specs, >>    and they'd just need some setting down of paving stones). >> >>    [4]: https://datatracker.ietf.org/doc/draft-ietf-core-href/ [Authors] This is an interesting proposal. This is a good alternative to having to use the well-known URI in both entities, leaving it only for the first message from the IoT device to the Controller, which makes sense. >> >> * (Bycatch of suggesting URIs): It may be worth mentioning that the >>    NON's source address can easily be spoofed. Thus, any device on the >>    network can trigger what the authenticator may think of as a >>    device-triggered reauthentication, and the device may think of as an >>    authenticator-triggered reauthentication (provided it works that way, >>    see below when reauthentication is mentioned again). >> [Authors] But this case would not be possible since we mention that (re) authentication is initiated by the device. Thus, when the device sees an authenticator triggered re-authentication will discard that. >>    Even sending full URIs in message 0 would be no worse than the >> current >>    source spoofing. >> >>    Sending URI paths in message 0 would make this minimally better >>    because the attacker would need to guess (or observe from the >> network) >>    the CoAP server's path. [Authors] Correct. >> >> * In 3.1 General flow, the message types are described in high detail. >>    CoAP can generally be used with different transports (some of which >>    don't even do NON/CON). Also, while I think it's reasonable to expect >>    that a CoAP implementation can deal with requests coming in as either >>    CON or NON, I'd expect that some don't offer all possible choices to >>    applications. (A very constrained device may only send NON requests, >>    or an implementation may decide autonomously whether to send >>    piggy-backed or not). >> [Authors] Regarding this, it is worth noting that, except for message 0, the constrained device (CoAP server) is not sending requests but responses. Therefore, it will receive CON requests sent by the non-so-constrained CoAP client (EAP authenticator) Regarding piggybacking, it would be a requirement for this specification, with the goal of saving messages. >>    Can you clarify as to what of this is meant to be normative and what >>    exemplary? >> >>    My recommendation is to state that what is prescribed is the flow of >>    requests and responses (which is what CoAP provides to the next >>    layer), while notes on reliable transmission are recommendations for >>    CoAP-over-UDP/DTLS. A similar statement, which I like a lot, is >>    already in 3.2 on error handling. [Authors] This may be tricky as per the operation of CoAP-EAP. See comments below. >> >>    (I can serve examples of how subtle incompatibilities can develop but >>    go unnoticed, but I'd only go through that if this is all really >>    intended to be prescriptive). >> [Authors] In principle, they are intended to be prescriptive. Therefore, it would be really appreciated if you list the incompatibilities you have in mind. Having said this, relaxing the piggybacked responses in the specification is something that we understand that should not be a problem, except the “undesirable” increment of messages over a constrained link. About the usage of NON or CON, the situation is the following. First of all, as mentioned, the CON request is done by the Controller, which is assumed to be a not-so-constrained device. So we do not foresee a problem there. In any case, we have spent several cycles trying to think how everything would work in the case of using NON, assuming the HATEOAS approach. As Mohit Sethi also commented, “EAP  provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees” (from RFC 3748). Therefore, there was a chance to use NON requests and responses with the help of EAP. To achieve  “ordering guarantees” we have the HATEOAS approach, but in the case of using NON request and responses, as we see it,  the CoAP server would need to handle two resources at the same time. This is the reason. If , for example, message 4 (below) is lost (where the new resource is informed), the CoAP client will not know that the following NON request in the sequence should go to resource /a/y . The only resources still known by CoAP client is /a/x. That means that resource /a/x MUST not be removed yet from the CoAP server. So the CoAP server keeps two resources: current step /a/x and next expected step in /a/y.  If a message from the CoAP client arrives to /a/x it MUST be considered a retransmission from the EAP authenticator state machine because the CoAP client did not receive the new resource /a/y. This EAP retransmission is handled by the EAP peer state machine, though at the application level we could silently discard the payload. However if the NON request arrives to /a/y in message 5, it means that the CoAP client received message 4. In such a case, /a/x is removed , /a/y is the current step and, for example, /a/z becomes the next expected resource. NON [0x8694] POST /a/x |               |                            Token (0xac) |               |                     Payload EAP-X-Req 1 |            3) |<----------------------------------------|               | NON [0x4754]                            |               | Token (0xac)                            |               | 2.01 Created Location-Path [/a/y]       |               | Payload EAP-X-Resp 1                    |            4) |---------------------------------------->| Moreover, each retransmitted EAP request will go to a newNON request to /a/x (with different token values). It may happen that both arrive to the CoAP server that answers with two different NON responses saying that the next resource is /a/y. If one of the NON responses indicating /a/y arrives very much later when the interaction moved forward and it is in resource, let’s say, /a/z, when CoAP client sees /a/y will think that next rsource is let’s say /a/y instead /a/z. That, the CoAP client will process the “old” NON response that said /a/y , when that resource is not available. Therefore the CoAP client would need to keep track, at the application level, of the resources already seen. Otherwise, the CoAP client might get confused. Therefore we are carrying the complexity to the application when this is something it could be solved with CON requests at CoAP level. Finally, another problem we see is that EAP success is not retransmitted, so we believe that, at least, would require a CON request. Therefore, when NON request and responses are used, we need to specify this kind of behaviour in the CoAP server. And that behaviour changes if we are using CON requests because keeping two resources is not necessary.  Is this reasonable?. >> * The reuse of the empty token only works if the peers actually respond >>    with piggy-backed responses, so that's where enforcing the above >> rules >>    would give some benefit -- but at the cost of losing existing CoAP >>    implementations that make no guarantees as to how the response >> will be >>    sent as long as it's reliable. >> [Authors] The use of the Token empty in this case is just proposed as an optimization to be used when possible. This is not intended to be prescriptive. And using NON request and responses we believe should not have an empty value. >> * Proxying: As it is right now, this protocol just barely works across >>    proxies, and only if they support CoAP-EAP explicitly. (And while it >>    may sound odd to even consider that, bear in mind that they are used >>    in a very similar way in RFC9031). >> >>    While it's a bit open whether all CoAP-based protocols should >>    reasonably be expected to work across proxies or not, a remark (maybe >>    before 3.1?) that "If CoAP proxies are used between EAP peer and EAP >>    authenticator, they must be configured with knowledge of this >>    specification, or the operations will fail after step 0." [Authors] Based on your comment, it seems there is no guarantee that any CoAP-based protocol would work across proxies. Our question is whether there is any adaptation or change that would favour working through proxies. At the research level, we worked with proxy and you are right, our assumption is that proxies support CoAP-EAP explicitly (https://ieeexplore.ieee.org/document/8467302 ).  Since we are trying to avoid right now anything tailored to CoAP-EAP and only using CoAP as a means of transport for the exchange, why do you think this would not work with proxies? >> >> * 3.2.2: The use of RST is rather unusual here, for the same reasons as >>    the prescriptive message types. >> >>    A response of 5.03 (Service Unavailable) has roughly the same size, >>    is available independent of transport, and on most libraries *way* >>    easier to use, if they support sending an RST to a well-formed >> message >>    at all. >> >>    (Furthermore, the sender of the 5.03 can encode an estimate of the >>    remaining unavailable time in the Max-Age option; not sure if that is >>    of any help here). >> >> * 3.3.1: "received with the ACK", "sends piggybacked response" are, >>    again, overly specific. "received in the last response" and "sends a >>    response" could work as replacements even if message types are >>    presecriptive. [Authors] We used RST as the examples of the CoAP RFC seemed to convey that meaning when the endpoint is not in a position to respond to the request, but this seems to be an easier way to achieve the same goal. And as you say, if this is easier on implementations we should strive for that. >> >> * 3.3.1: "after the maximum retransmission attempts, the CoAP client >>    will remove the state from its side". >> >>    So the device that's being kicked from the network can delay its own >>    eviction for about a minute as long as it doesn't answer? >> [Authors] This is an interesting use case. To avoid this, we may have to change the behaviour, to a NON-message and just remove the state. >> * 3.3.2: Is reauthentication always triggered by the EAP peer, or can it >>    also be triggered by the authenticator? If the latter, will the >>    authenticator use /.well-known/a again, or POST something to the >>    resource from where it'd DELETE in 3.3.1? [Authors] The answer is yes, EAP peer always triggered the re-authentication, as it is the one interested in maintaining its membership within the domain, or even it could be dormant at some points. A use case for these is LoRaWAN nodes, that have the capability of starting the communication regardless of their class, whereas the Network server may not send a message until it has received something from the IoT device. >> >> * cryptosuites: What's the upgrade model of that hardcoded list? As it >>    is now, it looks pretty static, so updates would be through >> updates of >>    this document. The obvious alternative is an IANA registry with >>    ranges, policies and the usual pros and cons. >> >>    Then again, this is not the first nor last time AEAD algorithms with >>    their parametrization and hash functions are assigned aggregate >>    numbers (I-D.ietf-lake-edhoc comes to mind which has asymmetric algs >>    in the mix too; probably others as well); can we deduplicate this >> with >>    anything? (Possibly by bringing this up with COSE or OSCORE people). >> [Authors] In the next version we will propose a structure to add different parameters to the CoAP-EAP exchange. Within these parameters, we considered the extensibility of the crypto suite algorithms. >> * OSCORE derivation: Is it cryptographically necessary to derive *both* >>    a master secret and a master salt through KDF? (Sounds like a >>    needless step to me, as both only go into KDF once more when the >>    actual OSCORE parameters are derived). I *guess* there's a good >> reason >>    why the MSK is not used as the OSCORE IKM right away and the CSO as >>    OSCORE master salt, but it'd help to have at list a comment here on >>    why that's needed. >> >>    (It may be useful to compare this step to the HKDF steps in OSCORE; >>    their info element is always a 5-element array with a 4th "type" >>    element of "Key" or "IV"; other extractions might just hook in there >>    with different type values, maybe, and save everyone an extra >> handling >>    step). >> [Authors] You are right, there should be a clarification on why this is done the way it is. The main purpose is to use MSK  as the root key for key derivation. It is common practice with the usage of the MSK. If say key were compromised, another one could be derived from the MSK, without having to resort to a new bootstrapping to refresh the MSK. >> * OSCORE ID derivation: >> >>    * Randomly assigned full-length ideas look like an odd choice. They >>      are excessively long (nonce length - 6 is 7 for the MTI >>      AES-CCM-16-64-128 and shorter for other current ones, but I doubt >>      that keeping the IV *short* is necessarily a design criterion for >>      future algorithms). >> >>      What commonly happens here (eg. in the ACE-OSCORE profile, or in >>      EDHOC) is that each party picks a recipient ID out of its pool of >>      currently unused IDs. This makes for shorter keys, and allows the >>      client to be sure that no two peers use the same context. >> >>      Any chance something like that can still make it in? >> [Authors] Did not see that as random but parametrised according to the crypto suite. We will try to make this as straightforward as possible following your comments. >>    * If the parties happen to be assigned the same sender ID, bad things >>      happen (identical key derivation, nonce reuse, nuclear meltdown). >> >>      If the current pattern of KDF'ing IDs stands, this needs to be >>      prevented explicitly. [Authors] Since the Sender and recipient IDs, are derived from the MSK, which is assumed to be fresh key material, I think this should not be a problem. >> >>    * The derivations of "OSCORE RECIPIENT ID" and "OSCORE SENDER ID" are >>      confusing as they each need to happen on both sides, and the terms >>      will match on one and need to be opposite on the other. >> >>      (I couldn't even easily find which is intended to be which). >> >>      My suggestion is to derive "OSCORE EAP PEER SENDER ID" and "OSCORE >>      AUTHENTICATOR SENDER ID" instead. (Or preferably shorter strings). >> [Authors] Good point, thank you. We will address this according to your suggestion. >> * Exmaples: Do you envision particular EAP protocols to be used in the >>    given examples? [Authors] We consider the examples to use lightweight EAP methods. This could be EAP-PSK for instance. >> >> Best regards >> Christian --------------7CFFD4FA37F207B354D8AA67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQogIDwvaGVhZD4NCiAgPGJvZHk+DQogICAgPHAgZGly PSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0 b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC1jZmYxZmE4ZC03ZmZmLTQ5NjktZTdmMS04 MWZjMGMxY2QzMGYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDtmb250LXdlaWdo dDo0MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29yYXRp b246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3Bh Y2U6cHJlLXdyYXA7Ij5EZWFyIENocmlzdGlhbiwmbmJzcDs8L3NwYW4+PC9wPg0KICAgIDxicj4N CiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7bWFyZ2luLXRvcDowcHQ7 bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9u dC13ZWlnaHQ6NDAwO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1k ZWNvcmF0aW9uOm5vbmU7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3do aXRlLXNwYWNlOnByZS13cmFwOyI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBkZXRhaWxl ZCByZXZpc2lvbiwmbmJzcDs8L3NwYW4+PC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFj a2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDtmb250LXdlaWdodDo0MDA7Zm9udC1zdHlsZTpub3Jt YWw7Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGln bjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij5QbGVhc2Ug c2VlIGlubGluZSBvdXIgY29tbWVudHMuIA0KPC9zcGFuPjwvcD4NCiAgICA8cCBkaXI9Imx0ciIg c3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjoj MDAwMDAwO2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9udC13ZWlnaHQ6NDAwO2ZvbnQt c3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dmVy dGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3doaXRlLXNwYWNlOnByZS13cmFw OyI+DQo8L3NwYW4+PC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4z ODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xv cjp0cmFuc3BhcmVudDtmb250LXdlaWdodDo0MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJp YW50Om5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3 aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij4NCjwvc3Bhbj48L3A+DQogICAg PGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpjOWNkYjIxNi01OWE3 LWIwNmEtN2NkMC05Mzg2ZTdiNmY5YWVAdW5pb3ZpLmVzIj5Pbg0KICAgICAgMTYvOC8yMSAxNjo0 MCwgQ2hyaXN0aWFuIEFtc8O8c3Mgd3JvdGU6DQogICAgICA8YnI+DQogICAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5IZWxsbyBDb0FQLUVBUCBhdXRob3JzIGFuZCBpbnZvbHZlZA0KICAgICAg ICBncm91cHMsDQogICAgICAgIDxicj4NCiAgICAgICAgKENDJ2luZyBjb3JlQCBhcyB0aGlzIGlz IGEgcmV2aWV3IG9uIENvQVAgdXNhZ2UpLA0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAg ICAgICAgPGJyPg0KICAgICAgICBJJ3ZlIHJlYWQgdGhlIC0wMyBkcmFmdCBhbmQgYWNjdW11bGF0 ZWQgYSBmZXcgY29tbWVudHM7IGxhcmdlbHkNCiAgICAgICAgaW4NCiAgICAgICAgPGJyPg0KICAg ICAgICBzZXF1ZW5jZSBvZiBvY2N1cnJlbmNlLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4N CiAgICAgICAgT3ZlciBhbGwsIHRoZSBwcm90b2NvbCBoYXMgaW1wcm92ZWQgYSBsb3Qgc2luY2Ug SSd2ZSBsYXN0IGhhZCBteQ0KICAgICAgICBleWVzIG9uDQogICAgICAgIDxicj4NCiAgICAgICAg aXQuIFNldmVyYWwgY29tbWVudHMgYmVsb3cgYXJlIGFib3V0IGhvdyBwcmVzY3JpcHRpdmUgdGhl DQogICAgICAgIG1lc3NhZ2UgdHlwZXMNCiAgICAgICAgPGJyPg0KICAgICAgICBhcmUuIEkgYmVs aWV2ZSB0aGF0IHRoaXMgc2hvdWxkIGJlIHJlc29sdmVkIHRvd2FyZHMgZ2VuZXJhbGl0eSwNCiAg ICAgICAgb3IgZWxzZQ0KICAgICAgICA8YnI+DQogICAgICAgIHRoZSB1c2FiaWxpdHkgb2YgdGhp cyBwcm90b2NvbCB3aXRoIGdlbmVyaWMgQ29BUCBjb21wb25lbnRzIHdpbGwNCiAgICAgICAgYmUN CiAgICAgICAgPGJyPg0KICAgICAgICBsaW1pdGVkIChvciwgd29yc2UsIHN0aWxsIGltcGxlbWVu dGVkIGFuZCB0aGVuIHN1cnByaXNpbmdseQ0KICAgICAgICA8YnI+DQogICAgICAgIGluY29tcGF0 aWJsZSkuDQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAg ICogRmlndXJlIDE6IEZvciByZWFkZXJzIG5ldyB0byB0aGUgdG9waWMgb2YgRUFQLCBJIHRoaW5r IHRoYXQgaXQNCiAgICAgICAgbWlnaHQNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJz cDsgYmUgdXNlZnVsIHRvIGV4dGVuZCB0aGlzIHRvIGNvdmVyIGFsc28gdGhlIEVBUCBzZXJ2ZXIg b3IgQUFBDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGluZnJhc3RydWN0dXJl LCBpZiB0aGF0IGNhbiBiZSBjb3ZlcmVkIHdpdGhvdXQgdG9vIG11Y2gNCiAgICAgICAgY29tcGxp Y2F0aW9uLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7 IFN1Z2dlc3Rpb24gKHdpdGhvdXQgaWxsdXNpb25zIG9mIGNvcnJlY3RuZXNzKToNCiAgICAgICAg PGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJb1QgZGV2aWNlJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENvbnRyb2xsZXINCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0tLS0tLS0tLS0tLSsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0tLS0tLS0tLS0tLSsNCiAgICAgICAg PGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCBFQVAgcGVlci8mbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IEVBUCBhdXRoLi8gfCstLS0tLStbIEFBQQ0KICAgICAgICBpbmZy YS4gXQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IENvQVAgc2VydmVyfCstLS0tLS0rfCBDb0FQIGNs aWVudHwrLS0tLS0rWyBFQVANCiAgICAgICAgc2VydmVyP10NCiAgICAgICAgPGJyPg0KICAgICAg ICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Ky0tLS0tLS0tLS0tLSsmbmJzcDsgQ29BUCZuYnNwOyArLS0tLS0tLS0tLS0tKyZuYnNwOyBFQVA/ DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBcX19fX18gU2NvcGUgb2YgdGhpcyBkb2N1bWVudCBfX19fXy8NCiAgICAg ICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUg MTogQ29BUC1FQVAgQXJjaGl0ZWN0dXJlDQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAg ICAgPC9ibG9ja3F1b3RlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAw KTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246 IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBpZD0iZG9jcy1pbnRlcm5hbC1ndWlk LTlmMDVjZDNhLTdmZmYtNDdkYy0zMGEwLWVlMWU4NWE0NDRkMCI+W0F1dGhvcnNdIFRoaXMgaXMg YSBnb29kIHBvaW50LiBXZSBkaWQgbm90IGluY2x1ZGUgaXQgYXQgZmlyc3QsIGFzIGhhdmluZyBh IEFBQSBpbmZyYXN0cnVjdHVyZSBpcyBub3QgbWFuZGF0b3J5LiBCdXQgdGhlIG9wdGlvbmFsaXR5 IGNhbiBhbHNvIGJlIGV4cHJlc3NlZCBpbiB0aGUgZmlndXJlLiBXZSB3aWxsIGNvbnNpZGVyIHVz aW5nIHRoaXMgZm9yIHRoZSBuZXh0IHZlcnNpb24uIFBsZWFzZSBhbHNvIGJlIGF3YXJlIHRoYXQg dGhpcyBhcmNoaXRlY3R1cmUgaW5jbHVkaW5nIEFBQSBpcyBhc3N1bWluZyBzb21ldGhpbmcgY2Fs bGVkIEVBUCBhdXRoZW50aWNhdG9yIGluIHBhc3MtdGhyb3VnaCBtb2RlLiBOZXZlcnRoZWxlc3Ms IGFuIEVBUCBhdXRoZW50aWNhdG9yIGluIHN0YW5kYWxvbmUgbW9kZSBpcyBhbHNvIHBvc3NpYmxl LCB3aGVyZSBubyBBQUEgZXhpc3RzLjwvc3Bhbj48L3A+DQogICAgPHA+PGJyPg0KICAgIDwvcD4N CiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6YzljZGIyMTYtNTlhNy1iMDZh LTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAgICA8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4qIGAvLndlbGwta25vd24vYWA6IFtub3RlOiBNYXkgYmUNCiAgICAgICAgaXJyZWxldmFu dCwgc2VlIG5leHQgdHdvIGl0ZW1zXQ0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAg ICAgJm5ic3A7Jm5ic3A7IElmIHRoZSBkZXNpZ25hdGVkIGV4cGVydHMgZG9uJ3QgZ28gYWxvbmcg d2l0aCBhDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHZlcnktc2hvcnQgb3B0 aW9uIChJJ2Qga2luZCBvZiBkb3VidCB5b3UnZCBnZXQgYW55dGhpbmcNCiAgICAgICAgc2hvcnRl ciB0aGFuDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGAvLndlbGwta25vd24v ZWFwYCkgYW5kIGlmIHRoYXQgcHV0cyB5b3UgdXAgYWdhaW5zdCBwcmFjdGljYWwNCiAgICAgICAg bGltaXRzLA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB1c2luZyBhIHNob3J0 LWhhbmQgb3B0aW9uIG1pZ2h0IGJlIHZpYWJsZS4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+ DQogICAgICAgICZuYnNwOyZuYnNwOyBTbyBmYXIgdGhlcmUncyBubyBkb2N1bWVudCBmb3IgaXQg YW5kIEkndmUgb25seSBwaXRjaGVkIHRoZQ0KICAgICAgICBpZGVhDQogICAgICAgIDxicj4NCiAg ICAgICAgJm5ic3A7Jm5ic3A7IGJyaWVmbHkgYXQgYW4gaW50ZXJpbVsxXSAoc2xpZGVzIGF0IFsy XSksIGJ1dCBpZiBwdXNoIGNvbWVzDQogICAgICAgIHRvIHNob3ZlDQogICAgICAgIDxicj4NCiAg ICAgICAgJm5ic3A7Jm5ic3A7IGFuZCB5b3UgbmVlZCB0aGUgY29tcGFjdG5lc3MsIGxldCBtZSBr bm93IGFuZCB0aGF0IHdvcmsgY2FuDQogICAgICAgIGJlDQogICAgICAgIDxicj4NCiAgICAgICAg Jm5ic3A7Jm5ic3A7IGV4cGVkaXRlZC4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAg ICAgICZuYnNwOyZuYnNwOyBbMV06DQogICAgICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJl ZXRleHQiIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmlt LTIwMjEtY29yZS0wNS9zZXNzaW9uL2NvcmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bWVldGluZy9pbnRlcmltLTIwMjEtY29yZS0wNS9zZXNzaW9uL2NvcmU8L2E+DQogICAgICAgIDxi cj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IFsyXToNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJl ZXRleHQiIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmlt LTIwMjEtY29yZS0wNS9tYXRlcmlhbHMvc2xpZGVzLWludGVyaW0tMjAyMS1jb3JlLTA1LXNlc3Nh LWNvcmUtb3B0aW9uLWZvci13ZWxsLWtub3duLXJlc291cmNlcy0wMCI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAyMS1jb3JlLTA1L21hdGVyaWFscy9zbGlk ZXMtaW50ZXJpbS0yMDIxLWNvcmUtMDUtc2Vzc2EtY29yZS1vcHRpb24tZm9yLXdlbGwta25vd24t cmVzb3VyY2VzLTAwPC9hPjxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVv dGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6 MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC0wNDM1NjAyNy03 ZmZmLTY1MzEtZTIyMC1jYjJjZjE1N2NjNWIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNv bG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRl LXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBZb3UgYXJlIGNvcnJlY3QuIFRoaXMgd2FzIGFk ZHJlc3NlZCBieSB0aGUgd2VsbC1rbm93biBVUkkgZXhwZXJ0cyBhbmQgdGhleSBoYXZlIHByb3Bv c2VkIHRvIHVzZSAvLndlbGwta25vd24vY29hcC1lYXA8L3NwYW4+PC9wPg0KICAgIDxwPjxicj4N CiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2 LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxicj4NCiAgICAgICAgKiBEaXNjb3ZlcmluZyB0aGUg Q29udHJvbGxlciBpcyBkZXNjcmliZWQgcmF0aGVyIGdlbmVyaWNhbGx5LA0KICAgICAgICBidXQg d2l0aA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBDb0FQIGRpc2NvdmVyeSBh cyBhbiBleGFtcGxlLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7 Jm5ic3A7IEFzIGxvbmcgYXMgQ29BUCBkaXNjb3ZlcnkgKGFzIHBlciBSRkM2NjkwLzcyNTIpIGlz IHVzZWQsIHRoYXQNCiAgICAgICAgYWxyZWFkeQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNw OyZuYnNwOyBwcm9kdWNlcyBhIFVSSSwgd2hpY2ggY2FuIGNvbnRhaW4gYW55IHBhdGggdGhlIHNl cnZlciBwaWNrZWQuDQogICAgICAgIEl0IGhhcw0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNw OyZuYnNwOyB0aHVzIG5vIG5lZWQgZm9yIGEgd2VsbC1rbm93biBwYXRoLg0KICAgICAgICA8YnI+ DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IEFyZSB0aGVyZSBvdGhlciBkaXNj b3Zlcnkgb3B0aW9ucyBlbnZpc2lvbmVkIHRoYXQnZCBvbmx5DQogICAgICAgIHJlc3VsdCBpbiBh DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IG5ldHdvcmsgYWRkcmVzcz8gT25s eSBmb3IgdGhlc2UsIGEgd2VsbC1rbm93biBwYXRoIHdvdWxkIG1ha2UNCiAgICAgICAgc2Vuc2Uu DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IChBbmQgdGhlbiBpdCdzIHVwIHRv IHRoZSBlbnZpc2lvbmVkIGNsaWVudCBjb21wbGV4aXR5IGlmIG9uZQ0KICAgICAgICBpcw0KICAg ICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB3YXJyYW50ZWQpLg0KICAgICAgICA8YnI+ DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQog ICAgPGJyPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4t dG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtYjUxMGE5 ODItN2ZmZi0zNjc4LTFiMjQtYWFkNmIyNmViYWZjIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3Vu ZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3 aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5bQXV0aG9yc10gVGhpcyBpcyByZWxhdGVkIHRvIHRoZSBu ZXh0IHBvaW50LiBBcyBsb25nIGFzIHRoZSBJb1QgZGV2aWNlIHNlbmRzIHRoZSByZXNvdXJjZSBm b3IgdGhlIGF1dGhlbnRpY2F0aW9uIGluIHRoaXMgY2FzZSB3ZSB3b3VsZCByZW1vdmUgdGhlIG5l ZWQgZm9yIHRoZSB3ZWxsLWtub3duIGluIHRoZSBJb1QgZGV2aWNlLiANCjwvc3Bhbj48L3A+DQog ICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21h cmdpbi1ib3R0b206MHB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5z cGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHBy ZS13cmFwOyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDtmb250LXdl aWdodDo3MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29y YXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUt c3BhY2U6cHJlLXdyYXA7Ij4NCjwvc3Bhbj48L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmku ZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+Jm5ic3A7Jm5ic3A7IEZvciBjb21w YXJpc29uLCBSRFszXSBleHBsb3JlcyBzb21lIG9mDQogICAgICAgIHRoZSBvcHRpb25zLiBBIHBh dGggbWF5IGJlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGRpc2NvdmVyZWQg dXNpbmcgQ29BUCBkaXNjb3ZlcnkgYXMgYD9ydD1jb3JlLnJkKmAgcmlnaHQgYXdheQ0KICAgICAg ICBmcm9tDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IG11bHRpY2FzdC4gT3Ig YW4gYWRkcmVzcyBtYXkgYmUgZGlzY292ZXJlZCB1c2luZyBhbiBJUHY2IFJBDQogICAgICAgIG9w dGlvbiwNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgd2l0aCBDb0FQIGRpc2Nv dmVyeSBhY3Rpbmcgb24gdGhhdCBhZGRyZXNzLiBPbmx5IGZvciBjYXNlcyBvZg0KICAgICAgICB2 ZXJ5DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHNpbXBsZSBlbmRwb2ludHMs IGl0IGFsc28gZGVmaW5lcyBhIGAvLndlbGwta25vd24vcmRgIG5hbWUNCiAgICAgICAgdGhhdCBj YW4gYmUNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgdXNlZCB3aXRob3V0IENv QVAgZGlzY292ZXJ5IChhbmQgdGh1cyBsaW5rIHBhcnNpbmcpIGhhcHBlbmluZw0KICAgICAgICA8 YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBiZWZvcmVoYW5kLiBUaGUgc2FtZSByYXRpb25hbGVz IG1heSBhcHBseSBmb3IgRUFQICh0aGUNCiAgICAgICAgZGV2aWNlcyB1c2luZw0KICAgICAgICA8 YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB0aGUgcmVzb3VyY2UgYXJlIG1vc3RseSBzZXJ2ZXJz LCBvdGhlcndpc2UsIGFuZCBzZW5kIGEgdmVyeQ0KICAgICAgICBzaW1wbGUNCiAgICAgICAgPGJy Pg0KICAgICAgICAmbmJzcDsmbmJzcDsgcmVxdWVzdCB0byBzdGFydCB0aGluZ3MpLCBidXQgYWdh aW4gdGhhdCdzIG9ubHkgaWYgdGhlDQogICAgICAgIGFkZHJlc3Mgd2FzDQogICAgICAgIDxicj4N CiAgICAgICAgJm5ic3A7Jm5ic3A7IGRpc2NvdmVyZWQgdGhyb3VnaCBzb21ldGhpbmcgdGhhdCdz IG5vdCBDb0FQIGRpc2NvdmVyeQ0KICAgICAgICBhbHJlYWR5Lg0KICAgICAgICA8YnI+DQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IFszXToNCjxhIGNsYXNzPSJtb3otdHh0LWxp bmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt aWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeS0yOC5odG1sI25hbWUtcmQtZGlzY292ZXJ5LWFu ZC1vdGhlci1pbnRlIj5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYt Y29yZS1yZXNvdXJjZS1kaXJlY3RvcnktMjguaHRtbCNuYW1lLXJkLWRpc2NvdmVyeS1hbmQtb3Ro ZXItaW50ZTwvYT48YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8 L2Jsb2NrcXVvdGU+DQogICAgPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRy YW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6 IHByZS13cmFwOyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC05MGMzNjdlYy03ZmZmLTk4MTQtM2Yy YS1iNzAyOGY1NTY4ZGQiPltBdXRob3JzXSBUaGlzIGlzIGEgZ29vZCBwb2ludC4gV2UgbWF5IG5l ZWQgdG8gYWRkIGEgZGlzY3Vzc2lvbiBvZiBob3cgdGhlIHNlcnZpY2UgY2FuIGJlIGRpc2NvdmVy ZWQgc2luY2UsIGFzIHlvdSBjb21tZW50ZWQsIHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyB0byBk byBzby4gT3VyIGluaXRpYWwgaWRlYSB3YXMgdG8gY29udGFjdCBkaXJlY3RseSB3aXRoIHRoZSBC b3JkZXIgUm91dGVyLCB3aGljaCBpcyBjb25zaXN0ZW50IHdpdGggd2hhdCB5b3UgY29tbWVudCBh Ym91dCByZWNlaXZpbmcgdGhlIElQdjYgUkEgdG8gcmVjZWl2ZSB0aGUgSVB2NiBBZGRyZXNzLiBI ZW5jZSB0aGUgY29tbXVuaWNhdGlvbiB3b3VsZCBiZSBkaXJlY3RseSB1c2luZyB0aGUgLy53ZWxs LWtub3duIFVSSSBhbmQgdGhlIGRpc2NvdmVyZWQgSVB2NiBhZGRyZXNzLiA8L3NwYW4+PC9wPg0K ICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0i bWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAg ICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KiBGb3IgbWVzc2FnZSAxLCB3aHkgZG9lcyB0aGlz IG5lZWQgdG8gZ28NCiAgICAgICAgdG8gYSBmaXhlZCByZXNvdXJjZT8gVGhlcmUgaGFzDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGJlZW4gcHJldmlvdXMgY29tbXVuaWNhdGlv biBpbiBtZXNzYWdlIDAgaW4gd2hpY2ggdGhlDQogICAgICAgIHJlc291cmNlIGNvdWxkDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGhhdmUgYmVlbiB0cmFuc3BvcnRlZC4NCiAg ICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBHcmFudGVkLCBp dCdzIG5vdCBhcyBlYXN5IGFzIGluIG1lc3NhZ2VzIDItdG8tMyBldGMgd2hlcmUgdGhlDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IExvY2F0aW9uLSogb3B0aW9ucyBhcmUgYXJv dW5kLCBidXQgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgMA0KICAgICAgICBQT1NUIGNvdWxkDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGp1c3QgYXMgd2VsbCBjb250YWluIHRoZSBw YXRoIGluIHRoZSBwYXlsb2FkLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAg Jm5ic3A7Jm5ic3A7IFRoZXJlIGFyZSBvcHRpb25zIGFzIHRvIGhvdyB0byBkbyB0aGF0IHByZWNp c2VseSAoanVzdCB0aGUNCiAgICAgICAgVVJJDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7 Jm5ic3A7IHJlZmVyZW5jZSBpbiB0ZXh0IGZvcm0sIG9yIGEgUkZDNjY5MCBsaW5rLCBvciBhIENC T1IgbGlzdCBvZg0KICAgICAgICBwYXRoDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5i c3A7IHNlZ21lbnRzLCBvciBhIENSSSByZWZlcmVuY2VbNF0gLS0gaWYgdGhlIGxhdHRlciB3ZXJl IGluIFdHTEMNCiAgICAgICAgYWxyZWFkeQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZu YnNwOyBJJ2QgcmVjb21tZW5kIGl0IHdob2xlaGVhcnRlZGx5KSwgYnV0IGVpdGhlciBvZiB0aGVt IHdvdWxkDQogICAgICAgIHN0YXkgbW9yZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZu YnNwOyB0cnVlIHRvIHRoZSBzdHlsZSBvZiB0aGUgb3RoZXIgbWVzc2FnZXMgaW4gdGhhdCB0aGUg ZWFybGllcg0KICAgICAgICBtZXNzYWdlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5i c3A7IGluZm9ybXMgdGhlIHBhdGggY2hvaWNlIG9mIHRoZSBuZXh0IG9uZXMuDQogICAgICAgIDxi cj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgQW4gdXBzaWRlIG9mIHRoaXMg d291bGQgYmUgdGhhdCBpdCBhbGxvd3MgYmV0dGVyIGJlaGF2aW9yIGluDQogICAgICAgIHByZXNl bmNlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IG9mIHByb3hpZXMgKHNlZSBs YXRlciksIGV2ZW4gdGhvdWdoIGl0IG1heSBiZSBwcmFjdGljYWwgdG8NCiAgICAgICAgbm90IHNw ZWMNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgdGhhdCBvdXQgaW4gZnVsbCBo ZXJlLiAoQnV0IHRoZSBwYXRoIHdvdWxkIGJlIG9wZW4gZm9yDQogICAgICAgIGZ1cnRoZXIgc3Bl Y3MsDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGFuZCB0aGV5J2QganVzdCBu ZWVkIHNvbWUgc2V0dGluZyBkb3duIG9mIHBhdmluZyBzdG9uZXMpLg0KICAgICAgICA8YnI+DQog ICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IFs0XTogPGEgY2xhc3M9Im1vei10eHQt bGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1jb3JlLWhyZWYvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWNvcmUtaHJlZi88L2E+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4N CiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0 OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29s b3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUt c3BhY2U6IHByZS13cmFwOyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC0yY2E0NmMwOS03ZmZmLWVi NzItZjFjNi1iZGY1MzA0ZTE5ZGYiPltBdXRob3JzXSBUaGlzIGlzIGFuIGludGVyZXN0aW5nIHBy b3Bvc2FsLiBUaGlzIGlzIGEgZ29vZCBhbHRlcm5hdGl2ZSB0byBoYXZpbmcgdG8gdXNlIHRoZSB3 ZWxsLWtub3duIFVSSSBpbiBib3RoIGVudGl0aWVzLCBsZWF2aW5nIGl0IG9ubHkgZm9yIHRoZSBm aXJzdCBtZXNzYWdlIGZyb20gdGhlIElvVCBkZXZpY2UgdG8gdGhlIENvbnRyb2xsZXIsIHdoaWNo IG1ha2VzIHNlbnNlLiA8L3NwYW4+PC9wPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNp dGU9Im1pZDpjOWNkYjIxNi01OWE3LWIwNmEtN2NkMC05Mzg2ZTdiNmY5YWVAdW5pb3ZpLmVzIj4N CiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICA8YnI+DQogICAgICAgICog KEJ5Y2F0Y2ggb2Ygc3VnZ2VzdGluZyBVUklzKTogSXQgbWF5IGJlIHdvcnRoIG1lbnRpb25pbmcg dGhhdA0KICAgICAgICB0aGUNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgTk9O J3Mgc291cmNlIGFkZHJlc3MgY2FuIGVhc2lseSBiZSBzcG9vZmVkLiBUaHVzLCBhbnkgZGV2aWNl DQogICAgICAgIG9uIHRoZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBuZXR3 b3JrIGNhbiB0cmlnZ2VyIHdoYXQgdGhlIGF1dGhlbnRpY2F0b3IgbWF5IHRoaW5rIG9mIGFzIGEN CiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgZGV2aWNlLXRyaWdnZXJlZCByZWF1 dGhlbnRpY2F0aW9uLCBhbmQgdGhlIGRldmljZSBtYXkgdGhpbmsNCiAgICAgICAgb2YgYXMgYW4N CiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYXV0aGVudGljYXRvci10cmlnZ2Vy ZWQgcmVhdXRoZW50aWNhdGlvbiAocHJvdmlkZWQgaXQgd29ya3MNCiAgICAgICAgdGhhdCB3YXks DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHNlZSBiZWxvdyB3aGVuIHJlYXV0 aGVudGljYXRpb24gaXMgbWVudGlvbmVkIGFnYWluKS4NCiAgICAgICAgPGJyPg0KICAgICAgICA8 YnI+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwIGRpcj0i bHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9t OjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtYzA4OGNhOGYtN2ZmZi0yODJjLWJlMDgtMzVk ZDliNTE5MzlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBB cmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7 Ij5bQXV0aG9yc10gQnV0IHRoaXMgY2FzZSB3b3VsZCBub3QgYmUgcG9zc2libGUgc2luY2Ugd2Ug bWVudGlvbiB0aGF0IChyZSkgYXV0aGVudGljYXRpb24gaXMgaW5pdGlhdGVkIGJ5IHRoZSBkZXZp Y2UuIFRodXMsIHdoZW4gdGhlIGRldmljZSBzZWVzIGFuIGF1dGhlbnRpY2F0b3IgdHJpZ2dlcmVk IHJlLWF1dGhlbnRpY2F0aW9uIHdpbGwgZGlzY2FyZCB0aGF0Ljwvc3Bhbj48L3A+DQogICAgPHA+ PGJyPg0KICAgIDwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6Yzlj ZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4mbmJzcDsmbmJzcDsgRXZlbiBzZW5kaW5nIGZ1bGwgVVJJcyBp biBtZXNzYWdlIDANCiAgICAgICAgd291bGQgYmUgbm8gd29yc2UgdGhhbiB0aGUgY3VycmVudA0K ICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBzb3VyY2Ugc3Bvb2ZpbmcuDQogICAg ICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgU2VuZGluZyBVUkkg cGF0aHMgaW4gbWVzc2FnZSAwIHdvdWxkIG1ha2UgdGhpcyBtaW5pbWFsbHkNCiAgICAgICAgYmV0 dGVyDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGJlY2F1c2UgdGhlIGF0dGFj a2VyIHdvdWxkIG5lZWQgdG8gZ3Vlc3MgKG9yIG9ic2VydmUgZnJvbSB0aGUNCiAgICAgICAgbmV0 d29yaykNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgdGhlIENvQVAgc2VydmVy J3MgcGF0aC4NCiAgICAgICAgPGJyPg0KICAgICAgPC9ibG9ja3F1b3RlPg0KICAgIDwvYmxvY2tx dW90ZT4NCiAgICA8YnI+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4 O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3Vp ZC0xNWZjYzdjZi03ZmZmLTg3OWMtNWQxYy0yMzUzZmFhZDEwYjMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBi YWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBDb3JyZWN0Ljwvc3Bhbj48 L3A+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6 MHB0O21hcmdpbi1ib3R0b206MHB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6 IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3Bh Y2U6IHByZS13cmFwOyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDtm b250LXdlaWdodDo3MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0 LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7 d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij4NCjwvc3Bhbj48L3A+DQogICAgPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1 bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxicj4N CiAgICAgICAgKiBJbiAzLjEgR2VuZXJhbCBmbG93LCB0aGUgbWVzc2FnZSB0eXBlcyBhcmUgZGVz Y3JpYmVkIGluIGhpZ2gNCiAgICAgICAgZGV0YWlsLg0KICAgICAgICA8YnI+DQogICAgICAgICZu YnNwOyZuYnNwOyBDb0FQIGNhbiBnZW5lcmFsbHkgYmUgdXNlZCB3aXRoIGRpZmZlcmVudCB0cmFu c3BvcnRzIChzb21lIG9mDQogICAgICAgIHdoaWNoDQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IGRvbid0IGV2ZW4gZG8gTk9OL0NPTikuIEFsc28sIHdoaWxlIEkgdGhpbmsgaXQn cyByZWFzb25hYmxlDQogICAgICAgIHRvIGV4cGVjdA0KICAgICAgICA8YnI+DQogICAgICAgICZu YnNwOyZuYnNwOyB0aGF0IGEgQ29BUCBpbXBsZW1lbnRhdGlvbiBjYW4gZGVhbCB3aXRoIHJlcXVl c3RzIGNvbWluZyBpbg0KICAgICAgICBhcyBlaXRoZXINCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsgQ09OIG9yIE5PTiwgSSdkIGV4cGVjdCB0aGF0IHNvbWUgZG9uJ3Qgb2ZmZXIg YWxsIHBvc3NpYmxlDQogICAgICAgIGNob2ljZXMgdG8NCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsgYXBwbGljYXRpb25zLiAoQSB2ZXJ5IGNvbnN0cmFpbmVkIGRldmljZSBtYXkg b25seSBzZW5kIE5PTg0KICAgICAgICByZXF1ZXN0cywNCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsgb3IgYW4gaW1wbGVtZW50YXRpb24gbWF5IGRlY2lkZSBhdXRvbm9tb3VzbHkg d2hldGhlciB0byBzZW5kDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHBpZ2d5 LWJhY2tlZCBvciBub3QpLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxv Y2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5l LWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFs aWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+DQo8L3NwYW4+PC9wPg0KICAg IDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJn aW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3Bh cmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUt d3JhcDsiPltBdXRob3JzXSBSZWdhcmRpbmcgdGhpcywgaXQgaXMgd29ydGggbm90aW5nIHRoYXQs IGV4Y2VwdCBmb3IgbWVzc2FnZSAwLCB0aGUgY29uc3RyYWluZWQgZGV2aWNlIChDb0FQIHNlcnZl cikgaXMgbm90IHNlbmRpbmcgcmVxdWVzdHMgYnV0IHJlc3BvbnNlcy4gVGhlcmVmb3JlLCBpdCB3 aWxsIHJlY2VpdmUgQ09OIHJlcXVlc3RzIHNlbnQgYnkgdGhlIG5vbi1zby1jb25zdHJhaW5lZCBD b0FQIGNsaWVudCAoRUFQIGF1dGhlbnRpY2F0b3IpPC9zcGFuPjwvcD4NCiAgICA8YnI+DQogICAg PHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdp bi1ib3R0b206MHB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFy ZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13 cmFwOyI+UmVnYXJkaW5nIHBpZ2d5YmFja2luZywgaXQgd291bGQgYmUgYSByZXF1aXJlbWVudCBm b3IgdGhpcyBzcGVjaWZpY2F0aW9uLCB3aXRoIHRoZSBnb2FsIG9mIHNhdmluZyBtZXNzYWdlcy48 L3NwYW4+PC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPg0KPC9zcGFuPjwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjaXRlPSJtaWQ6YzljZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVu aW92aS5lcyI+DQogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4mbmJzcDsmbmJzcDsgQ2Fu IHlvdSBjbGFyaWZ5IGFzIHRvIHdoYXQgb2YgdGhpcyBpcw0KICAgICAgICBtZWFudCB0byBiZSBu b3JtYXRpdmUgYW5kIHdoYXQNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgZXhl bXBsYXJ5Pw0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7 IE15IHJlY29tbWVuZGF0aW9uIGlzIHRvIHN0YXRlIHRoYXQgd2hhdCBpcyBwcmVzY3JpYmVkIGlz IHRoZQ0KICAgICAgICBmbG93IG9mDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7 IHJlcXVlc3RzIGFuZCByZXNwb25zZXMgKHdoaWNoIGlzIHdoYXQgQ29BUCBwcm92aWRlcyB0byB0 aGUNCiAgICAgICAgbmV4dA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBsYXll ciksIHdoaWxlIG5vdGVzIG9uIHJlbGlhYmxlIHRyYW5zbWlzc2lvbiBhcmUNCiAgICAgICAgcmVj b21tZW5kYXRpb25zIGZvcg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBDb0FQ LW92ZXItVURQL0RUTFMuIEEgc2ltaWxhciBzdGF0ZW1lbnQsIHdoaWNoIEkgbGlrZSBhIGxvdCwN CiAgICAgICAgaXMNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYWxyZWFkeSBp biAzLjIgb24gZXJyb3IgaGFuZGxpbmcuDQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90 ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdo dDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJu YWwtZ3VpZC1lYWIzNmJmOC03ZmZmLTUyNTUtMmZjOS00OGRiMDQ5N2IwYzQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dy b3VuZC1jb2xvcjp0cmFuc3BhcmVudDtmb250LXdlaWdodDo0MDA7Zm9udC1zdHlsZTpub3JtYWw7 Zm9udC12YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij5bQXV0aG9yc10g VGhpcyBtYXkgYmUgdHJpY2t5IGFzIHBlciB0aGUgb3BlcmF0aW9uIG9mIENvQVAtRUFQLiBTZWUg Y29tbWVudHMgYmVsb3cuPC9zcGFuPjwvcD4NCiAgICA8cD48YnI+DQogICAgPC9wPg0KICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpjOWNkYjIxNi01OWE3LWIwNmEtN2NkMC05 Mzg2ZTdiNmY5YWVAdW5pb3ZpLmVzIj4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K ICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyAoSSBjYW4gc2VydmUgZXhhbXBsZXMg b2YgaG93IHN1YnRsZSBpbmNvbXBhdGliaWxpdGllcyBjYW4NCiAgICAgICAgZGV2ZWxvcCBidXQN CiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgZ28gdW5ub3RpY2VkLCBidXQgSSdk IG9ubHkgZ28gdGhyb3VnaCB0aGF0IGlmIHRoaXMgaXMgYWxsDQogICAgICAgIHJlYWxseQ0KICAg ICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBpbnRlbmRlZCB0byBiZSBwcmVzY3JpcHRp dmUpLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAg ICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4 O3RleHQtYWxpZ246DQogICAgICBqdXN0aWZ5O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206 MHB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQXJpYWw7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+W0F1 dGhvcnNdIEluIHByaW5jaXBsZSwgdGhleSBhcmUgaW50ZW5kZWQgdG8gYmUgcHJlc2NyaXB0aXZl LiBUaGVyZWZvcmUsIGl0IHdvdWxkIGJlIHJlYWxseSBhcHByZWNpYXRlZCBpZiB5b3UgbGlzdCB0 aGUgaW5jb21wYXRpYmlsaXRpZXMgeW91IGhhdmUgaW4gbWluZC48L3NwYW4+PC9wPg0KICAgIDxi cj4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7dGV4dC1hbGlnbjoN CiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigw LCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwt YWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5IYXZpbmcgc2FpZCB0aGlz LCA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+ cmVsYXhpbmcgdGhlIHBpZ2d5YmFja2VkIHJlc3BvbnNlcyBpbiB0aGUgc3BlY2lmaWNhdGlvbiBp cyBzb21ldGhpbmcgdGhhdCB3ZSB1bmRlcnN0YW5kIHRoYXQgc2hvdWxkIG5vdCBiZSBhIHByb2Js ZW0sIGV4Y2VwdCB0aGUg4oCcdW5kZXNpcmFibGXigJ0gaW5jcmVtZW50IG9mIG1lc3NhZ2VzIG92 ZXIgYSBjb25zdHJhaW5lZCBsaW5rLjwvc3Bhbj48L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0i bHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFsaWduOg0KICAgICAganVzdGlmeTtt YXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3Jv dW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7 IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPkFib3V0IHRoZSB1c2FnZSBvZiBOT04gb3IgQ09OLCB0 aGUgc2l0dWF0aW9uIGlzIHRoZSBmb2xsb3dpbmcuIEZpcnN0IG9mIGFsbCwgYXMgbWVudGlvbmVk LCB0aGUgQ09OIHJlcXVlc3QgaXMgZG9uZSBieSB0aGUgQ29udHJvbGxlciwgd2hpY2ggaXMgYXNz dW1lZCB0byBiZSBhIG5vdC1zby1jb25zdHJhaW5lZCBkZXZpY2UuIFNvIHdlIGRvIG5vdCBmb3Jl c2VlIGEgcHJvYmxlbSB0aGVyZS4gSW4gYW55IGNhc2UsIHdlIGhhdmUgc3BlbnQgc2V2ZXJhbCBj eWNsZXMgdHJ5aW5nIHRvIHRoaW5rIGhvdyBldmVyeXRoaW5nIHdvdWxkIHdvcmsgaW4gdGhlIGNh c2Ugb2YgdXNpbmcgTk9OLCBhc3N1bWluZyB0aGUgSEFURU9BUyBhcHByb2FjaC4mbmJzcDs8L3Nw YW4+PC9wPg0KICAgIDxicj4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEu Mzg7dGV4dC1hbGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRv bTowcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5B cyBNb2hpdCBTZXRoaSBhbHNvIGNvbW1lbnRlZCwg4oCcRUFQJm5ic3A7IHByb3ZpZGVzIGl0cyBv d24gc3VwcG9ydCBmb3IgZHVwbGljYXRlIGVsaW1pbmF0aW9uIGFuZCByZXRyYW5zbWlzc2lvbiwg YnV0IGlzIHJlbGlhbnQgb24gbG93ZXIgbGF5ZXIgb3JkZXJpbmcgZ3VhcmFudGVlc+KAnSAoZnJv bSBSRkMgMzc0OCkuJm5ic3A7PC9zcGFuPjwvcD4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9Imxp bmUtaGVpZ2h0OjEuMzg7dGV4dC1hbGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7 bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTog cHJlLXdyYXA7Ij5UaGVyZWZvcmUsIHRoZXJlIHdhcyBhIGNoYW5jZSB0byB1c2UgTk9OIHJlcXVl c3RzIGFuZCByZXNwb25zZXMgd2l0aCB0aGUgaGVscCBvZiBFQVAuIFRvIGFjaGlldmUmbmJzcDsg 4oCcb3JkZXJpbmcgZ3VhcmFudGVlc+KAnSB3ZSBoYXZlIHRoZSBIQVRFT0FTIGFwcHJvYWNoLCBi dXQgaW4gdGhlIGNhc2Ugb2YgdXNpbmcgTk9OIHJlcXVlc3QgYW5kIHJlc3BvbnNlcywgYXMgd2Ug c2VlIGl0LCZuYnNwOyB0aGUgQ29BUCBzZXJ2ZXIgd291bGQgbmVlZCB0byBoYW5kbGUgdHdvIHJl c291cmNlcyBhdCB0aGUgc2FtZSB0aW1lLiBUaGlzIGlzIHRoZSByZWFzb24uIElmICwgZm9yIGV4 YW1wbGUsIG1lc3NhZ2UgNCAoYmVsb3cpIGlzIGxvc3QgKHdoZXJlIHRoZSBuZXcgcmVzb3VyY2Ug aXMgaW5mb3JtZWQpLCB0aGUgQ29BUCBjbGllbnQgd2lsbCBub3Qga25vdyB0aGF0IHRoZSBmb2xs b3dpbmcgTk9OIHJlcXVlc3QgaW4gdGhlIHNlcXVlbmNlIHNob3VsZCBnbyB0byByZXNvdXJjZSAv YS95IC4gVGhlIG9ubHkgcmVzb3VyY2VzIHN0aWxsIGtub3duIGJ5IENvQVAgY2xpZW50IGlzIC9h L3guIFRoYXQgbWVhbnMgdGhhdCByZXNvdXJjZSAvYS94IE1VU1Qgbm90IGJlIHJlbW92ZWQgeWV0 IGZyb20gdGhlIENvQVAgc2VydmVyLiBTbyB0aGUgQ29BUCBzZXJ2ZXIga2VlcHMgdHdvIHJlc291 cmNlczogY3VycmVudCBzdGVwIC9hL3ggYW5kIG5leHQgZXhwZWN0ZWQgc3RlcCBpbiAvYS95LiZu YnNwOyBJZiBhIG1lc3NhZ2UgZnJvbSB0aGUgQ29BUCBjbGllbnQgYXJyaXZlcyB0byAvYS94IGl0 IE1VU1QgYmUgY29uc2lkZXJlZCBhIHJldHJhbnNtaXNzaW9uIGZyb20gdGhlIEVBUCBhdXRoZW50 aWNhdG9yIHN0YXRlIG1hY2hpbmUgYmVjYXVzZSB0aGUgQ29BUCBjbGllbnQgZGlkIG5vdCByZWNl aXZlIHRoZSBuZXcgcmVzb3VyY2UgL2EveS4gVGhpcyBFQVAgcmV0cmFuc21pc3Npb24gaXMgaGFu ZGxlZCBieSB0aGUgRUFQIHBlZXIgc3RhdGUgbWFjaGluZSwgdGhvdWdoIGF0IHRoZSBhcHBsaWNh dGlvbiBsZXZlbCB3ZSBjb3VsZCBzaWxlbnRseSBkaXNjYXJkIHRoZSBwYXlsb2FkLiBIb3dldmVy IGlmIHRoZSBOT04gcmVxdWVzdCBhcnJpdmVzIHRvIC9hL3kgaW4gbWVzc2FnZSA1LCBpdCBtZWFu cyB0aGF0IHRoZSBDb0FQIGNsaWVudCByZWNlaXZlZCBtZXNzYWdlIDQuIEluIHN1Y2ggYSBjYXNl LCAvYS94IGlzIHJlbW92ZWQgLCAvYS95IGlzIHRoZSBjdXJyZW50IHN0ZXAgYW5kLCBmb3IgZXhh bXBsZSwgL2EveiBiZWNvbWVzIHRoZSBuZXh0IGV4cGVjdGVkIHJlc291cmNlLiZuYnNwOzwvc3Bh bj48L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4z ODt0ZXh0LWFsaWduOg0KICAgICAganVzdGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9t OjBwdDsiPjxmb250IGZhY2U9IkNvdXJpZXINCiAgICAgICAgTmV3LCBDb3VyaWVyLCBtb25vc3Bh Y2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJh Y2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNl bGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTk9OIFsweDg2OTRdIFBPU1QgL2EveCB8PC9zcGFuPjwvZm9udD48L3A+DQogICAgPHAg ZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O3RleHQtYWxpZ246DQogICAgICBqdXN0 aWZ5O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyI+PGZvbnQgZmFjZT0iQ291cmll cg0KICAgICAgICBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJl bnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdy YXA7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBUb2tlbiAoMHhhYykgfDwvc3Bhbj48L2ZvbnQ+PC9wPg0KICAgIDxw IGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFsaWduOg0KICAgICAganVz dGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxmb250IGZhY2U9IkNvdXJp ZXINCiAgICAgICAgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFy ZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13 cmFwOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGF5bG9hZCBF QVAtWC1SZXEgMSB8PC9zcGFuPjwvZm9udD48L3A+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJs aW5lLWhlaWdodDoxLjM4O3RleHQtYWxpZ246DQogICAgICBqdXN0aWZ5O21hcmdpbi10b3A6MHB0 O21hcmdpbi1ib3R0b206MHB0OyI+PGZvbnQgZmFjZT0iQ291cmllcg0KICAgICAgICBOZXcsIENv dXJpZXIsIG1vbm9zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGlj YWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDszKSB8 Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18PC9zcGFuPjwvZm9u dD48L3A+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdodDoxLjM4O3RleHQtYWxp Z246DQogICAgICBqdXN0aWZ5O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyI+PGZv bnQgZmFjZT0iQ291cmllcg0KICAgICAgICBOZXcsIENvdXJpZXIsIG1vbm9zcGFjZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1j b2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0 ZS1zcGFjZTogcHJlLXdyYXA7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8IE5PTiBbMHg0 NzU0XSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwvc3Bhbj48L2Zv bnQ+PC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFs aWduOg0KICAgICAganVzdGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxm b250IGZhY2U9IkNvdXJpZXINCiAgICAgICAgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQt Y29sb3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hp dGUtc3BhY2U6IHByZS13cmFwOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBUb2tlbiAo MHhhYykmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L3NwYW4+PC9m b250PjwvcD4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7dGV4dC1h bGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7Ij48 Zm9udCBmYWNlPSJDb3VyaWVyDQogICAgICAgIE5ldywgQ291cmllciwgbW9ub3NwYWNlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgMi4wMSBD cmVhdGVkIExvY2F0aW9uLVBhdGggWy9hL3ldICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L3NwYW4+ PC9mb250PjwvcD4NCiAgICA8cCBkaXI9Imx0ciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMzg7dGV4 dC1hbGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7 Ij48Zm9udCBmYWNlPSJDb3VyaWVyDQogICAgICAgIE5ldywgQ291cmllciwgbW9ub3NwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3Jv dW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7 IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgUGF5 bG9hZCBFQVAtWC1SZXNwIDEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwvc3Bhbj48L2ZvbnQ+PC9wPg0KICAgIDxw IGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFsaWduOg0KICAgICAganVz dGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxmb250IGZhY2U9IkNvdXJp ZXINCiAgICAgICAgTmV3LCBDb3VyaWVyLCBtb25vc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFy ZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13 cmFwOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7NCkgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0mZ3Q7fDwvc3Bhbj48L2ZvbnQ+PC9wPg0KICAgIDxicj4NCiAgICA8cCBkaXI9Imx0ciIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEuMzg7dGV4dC1hbGlnbjoNCiAgICAgIGp1c3RpZnk7bWFyZ2luLXRv cDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xv cjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1z cGFjZTogcHJlLXdyYXA7Ij5Nb3Jlb3ZlciwgZWFjaCByZXRyYW5zbWl0dGVkIEVBUCByZXF1ZXN0 IHdpbGwgZ28gdG8gYSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHRy YW5zcGFyZW50OyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtdmFyaWFudDogbm9ybWFsOyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6 IHByZS13cmFwOyI+bmV3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsiPiBOT04gcmVxdWVzdCB0byAvYS94ICh3aXRoIGRpZmZlcmVudCB0b2tlbiB2 YWx1ZXMpLiBJdCBtYXkgaGFwcGVuIHRoYXQgYm90aCBhcnJpdmUgdG8gdGhlIENvQVAgc2VydmVy IHRoYXQgYW5zd2VycyB3aXRoIHR3byBkaWZmZXJlbnQgTk9OIHJlc3BvbnNlcyBzYXlpbmcgdGhh dCB0aGUgbmV4dCByZXNvdXJjZSBpcyAvYS95LiBJZiBvbmUgb2YgdGhlIE5PTiByZXNwb25zZXMg aW5kaWNhdGluZyAvYS95IGFycml2ZXMgdmVyeSBtdWNoIGxhdGVyIHdoZW4gdGhlIGludGVyYWN0 aW9uIG1vdmVkIGZvcndhcmQgYW5kIGl0IGlzIGluIHJlc291cmNlLCBsZXTigJlzIHNheSwgL2Ev eiwgd2hlbiBDb0FQIGNsaWVudCBzZWVzIC9hL3kgd2lsbCB0aGluayB0aGF0IG5leHQgcnNvdXJj ZSBpcyBsZXTigJlzIHNheSAvYS95IGluc3RlYWQgL2Evei4gVGhhdCwgdGhlIENvQVAgY2xpZW50 IHdpbGwgcHJvY2VzcyB0aGUg4oCcb2xk4oCdIE5PTiByZXNwb25zZSB0aGF0IHNhaWQgL2EveSAs IHdoZW4gdGhhdCByZXNvdXJjZSBpcyBub3QgYXZhaWxhYmxlLiBUaGVyZWZvcmUgdGhlIENvQVAg Y2xpZW50IHdvdWxkIG5lZWQgdG8ga2VlcCB0cmFjaywgYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVs LCBvZiB0aGUgcmVzb3VyY2VzIGFscmVhZHkgc2Vlbi4gT3RoZXJ3aXNlLCB0aGUgQ29BUCBjbGll bnQgbWlnaHQgZ2V0IGNvbmZ1c2VkLiBUaGVyZWZvcmUgd2UgYXJlIGNhcnJ5aW5nIHRoZSBjb21w bGV4aXR5IHRvIHRoZSBhcHBsaWNhdGlvbiB3aGVuIHRoaXMgaXMgc29tZXRoaW5nIGl0IGNvdWxk IGJlIHNvbHZlZCB3aXRoIENPTiByZXF1ZXN0cyBhdCBDb0FQIGxldmVsLiZuYnNwOzwvc3Bhbj48 L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0 ZXh0LWFsaWduOg0KICAgICAganVzdGlmeTttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBw dDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBj b2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPkZpbmFs bHksIGFub3RoZXIgcHJvYmxlbSB3ZSBzZWUgaXMgdGhhdCBFQVAgc3VjY2VzcyBpcyBub3QgcmV0 cmFuc21pdHRlZCwgc28gd2UgYmVsaWV2ZSB0aGF0LCBhdCBsZWFzdCwgd291bGQgcmVxdWlyZSBh IENPTiByZXF1ZXN0LiZuYnNwOzwvc3Bhbj48L3A+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRy IiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODt0ZXh0LWFsaWduOg0KICAgICAganVzdGlmeTttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPlRoZXJlZm9yZSwgd2hlbiBOT04gcmVxdWVzdCBhbmQgcmVz cG9uc2VzIGFyZSB1c2VkLCB3ZSBuZWVkIHRvIHNwZWNpZnkgdGhpcyBraW5kIG9mIGJlaGF2aW91 ciBpbiB0aGUgQ29BUCBzZXJ2ZXIuIEFuZCB0aGF0IGJlaGF2aW91ciBjaGFuZ2VzIGlmIHdlIGFy ZSB1c2luZyBDT04gcmVxdWVzdHMgYmVjYXVzZSBrZWVwaW5nIHR3byByZXNvdXJjZXMgaXMgbm90 IG5lY2Vzc2FyeS4mbmJzcDsgSXMgdGhpcyByZWFzb25hYmxlPy48L3NwYW4+PC9wPg0KICAgIDxi cj4NCiAgICA8YnI+DQogICAgPGJyPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZl N2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KiBUaGUg cmV1c2Ugb2YgdGhlIGVtcHR5IHRva2VuIG9ubHkgd29ya3MNCiAgICAgICAgaWYgdGhlIHBlZXJz IGFjdHVhbGx5IHJlc3BvbmQNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgd2l0 aCBwaWdneS1iYWNrZWQgcmVzcG9uc2VzLCBzbyB0aGF0J3Mgd2hlcmUgZW5mb3JjaW5nIHRoZQ0K ICAgICAgICBhYm92ZSBydWxlcw0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB3 b3VsZCBnaXZlIHNvbWUgYmVuZWZpdCAtLSBidXQgYXQgdGhlIGNvc3Qgb2YgbG9zaW5nIGV4aXN0 aW5nDQogICAgICAgIENvQVANCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgaW1w bGVtZW50YXRpb25zIHRoYXQgbWFrZSBubyBndWFyYW50ZWVzIGFzIHRvIGhvdyB0aGUNCiAgICAg ICAgcmVzcG9uc2Ugd2lsbCBiZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBz ZW50IGFzIGxvbmcgYXMgaXQncyByZWxpYWJsZS4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+ DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwPjxiciBpZD0i ZG9jcy1pbnRlcm5hbC1ndWlkLTkwZTJjYmM4LTdmZmYtMDRkZC03NjgwLWZmM2NhYjBhZDg5ZSI+ DQogICAgPC9wPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBUaGUgdXNlIG9mIHRoZSBUb2tlbiBlbXB0 eSBpbiB0aGlzIGNhc2UgaXMganVzdCBwcm9wb3NlZCBhcyBhbiBvcHRpbWl6YXRpb24gdG8gYmUg dXNlZCB3aGVuIHBvc3NpYmxlLiBUaGlzIGlzIG5vdCBpbnRlbmRlZCB0byBiZSBwcmVzY3JpcHRp dmUuIEFuZCB1c2luZyBOT04gcmVxdWVzdCBhbmQgcmVzcG9uc2VzIHdlIGJlbGlldmUgc2hvdWxk IG5vdCBoYXZlIGFuIGVtcHR5IHZhbHVlLjwvc3Bhbj48L3A+DQogICAgPHA+PGJyPg0KICAgIDwv cD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6YzljZGIyMTYtNTlhNy1i MDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAgICA8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4qIFByb3h5aW5nOiBBcyBpdCBpcyByaWdodCBub3csIHRoaXMNCiAgICAgICAgcHJv dG9jb2wganVzdCBiYXJlbHkgd29ya3MgYWNyb3NzDQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IHByb3hpZXMsIGFuZCBvbmx5IGlmIHRoZXkgc3VwcG9ydCBDb0FQLUVBUCBleHBs aWNpdGx5LiAoQW5kDQogICAgICAgIHdoaWxlIGl0DQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IG1heSBzb3VuZCBvZGQgdG8gZXZlbiBjb25zaWRlciB0aGF0LCBiZWFyIGluIG1p bmQgdGhhdCB0aGV5DQogICAgICAgIGFyZSB1c2VkDQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IGluIGEgdmVyeSBzaW1pbGFyIHdheSBpbiBSRkM5MDMxKS4NCiAgICAgICAgPGJy Pg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBXaGlsZSBpdCdzIGEgYml0IG9w ZW4gd2hldGhlciBhbGwgQ29BUC1iYXNlZCBwcm90b2NvbHMgc2hvdWxkDQogICAgICAgIDxicj4N CiAgICAgICAgJm5ic3A7Jm5ic3A7IHJlYXNvbmFibHkgYmUgZXhwZWN0ZWQgdG8gd29yayBhY3Jv c3MgcHJveGllcyBvciBub3QsIGENCiAgICAgICAgcmVtYXJrIChtYXliZQ0KICAgICAgICA8YnI+ DQogICAgICAgICZuYnNwOyZuYnNwOyBiZWZvcmUgMy4xPykgdGhhdCAmcXVvdDtJZiBDb0FQIHBy b3hpZXMgYXJlIHVzZWQgYmV0d2VlbiBFQVAgcGVlcg0KICAgICAgICBhbmQgRUFQDQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGF1dGhlbnRpY2F0b3IsIHRoZXkgbXVzdCBiZSBj b25maWd1cmVkIHdpdGgga25vd2xlZGdlIG9mIHRoaXMNCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbiwgb3IgdGhlIG9wZXJhdGlvbnMgd2lsbCBmYWlsIGFm dGVyIHN0ZXAgMC4mcXVvdDsNCiAgICAgICAgPGJyPg0KICAgICAgPC9ibG9ja3F1b3RlPg0KICAg IDwvYmxvY2txdW90ZT4NCiAgICA8cD48YnIgaWQ9ImRvY3MtaW50ZXJuYWwtZ3VpZC1kMDFmZTlj MS03ZmZmLTQ5MTAtNjJkNy03MjM4YTM2ZmI3NjkiPg0KICAgICAgPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJh Y2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHZlcnRpY2FsLWFsaWduOiBiYXNl bGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+W0F1dGhvcnNdIEJhc2VkIG9uIHlvdXIgY29t bWVudCwgaXQgc2VlbXMgdGhlcmUgaXMgbm8gZ3VhcmFudGVlIHRoYXQgYW55IENvQVAtYmFzZWQg cHJvdG9jb2wgd291bGQgd29yayBhY3Jvc3MgcHJveGllcy4gT3VyIHF1ZXN0aW9uIGlzIHdoZXRo ZXIgdGhlcmUgaXMgYW55IGFkYXB0YXRpb24gb3IgY2hhbmdlIHRoYXQgd291bGQgZmF2b3VyIHdv cmtpbmcgdGhyb3VnaCBwcm94aWVzLiBBdCB0aGUgcmVzZWFyY2ggbGV2ZWwsIHdlIHdvcmtlZCB3 aXRoIHByb3h5IGFuZCB5b3UgYXJlIHJpZ2h0LCBvdXIgYXNzdW1wdGlvbiBpcyB0aGF0IHByb3hp ZXMgc3VwcG9ydCBDb0FQLUVBUCBleHBsaWNpdGx5ICg8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9p ZWVleHBsb3JlLmllZWUub3JnL2RvY3VtZW50Lzg0NjczMDIiIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246bm9uZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFy aWFsOyBjb2xvcjogcmdiKDE3LCA4NSwgMjA0KTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJl bnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyB0ZXh0LWRlY29yYXRpb24tc2tpcC1pbms6IG5vbmU7IHZlcnRpY2Fs LWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+aHR0cHM6Ly9pZWVleHBs b3JlLmllZWUub3JnL2RvY3VtZW50Lzg0NjczMDI8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBi YWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPikuJm5ic3A7IFNpbmNlIHdlIGFyZSB0cnlp bmcgdG8gYXZvaWQgcmlnaHQgbm93IGFueXRoaW5nIHRhaWxvcmVkIHRvIENvQVAtRUFQIGFuZCBv bmx5IHVzaW5nIENvQVAgYXMgYSBtZWFucyBvZiB0cmFuc3BvcnQgZm9yIHRoZSBleGNoYW5nZSwg d2h5IGRvIHlvdSB0aGluayB0aGlzIHdvdWxkIG5vdCB3b3JrIHdpdGggcHJveGllcz88L3NwYW4+ PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmkuZXMi Pg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxicj4NCiAgICAgICAg KiAzLjIuMjogVGhlIHVzZSBvZiBSU1QgaXMgcmF0aGVyIHVudXN1YWwgaGVyZSwgZm9yIHRoZSBz YW1lDQogICAgICAgIHJlYXNvbnMgYXMNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJz cDsgdGhlIHByZXNjcmlwdGl2ZSBtZXNzYWdlIHR5cGVzLg0KICAgICAgICA8YnI+DQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IEEgcmVzcG9uc2Ugb2YgNS4wMyAoU2VydmljZSBV bmF2YWlsYWJsZSkgaGFzIHJvdWdobHkgdGhlIHNhbWUNCiAgICAgICAgc2l6ZSwNCiAgICAgICAg PGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgaXMgYXZhaWxhYmxlIGluZGVwZW5kZW50IG9mIHRy YW5zcG9ydCwgYW5kIG9uIG1vc3QgbGlicmFyaWVzDQogICAgICAgICp3YXkqDQogICAgICAgIDxi cj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGVhc2llciB0byB1c2UsIGlmIHRoZXkgc3VwcG9ydCBz ZW5kaW5nIGFuIFJTVCB0byBhDQogICAgICAgIHdlbGwtZm9ybWVkIG1lc3NhZ2UNCiAgICAgICAg PGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYXQgYWxsLg0KICAgICAgICA8YnI+DQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IChGdXJ0aGVybW9yZSwgdGhlIHNlbmRlciBvZiB0 aGUgNS4wMyBjYW4gZW5jb2RlIGFuIGVzdGltYXRlDQogICAgICAgIG9mIHRoZQ0KICAgICAgICA8 YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyByZW1haW5pbmcgdW5hdmFpbGFibGUgdGltZSBpbiB0 aGUgTWF4LUFnZSBvcHRpb247IG5vdCBzdXJlIGlmDQogICAgICAgIHRoYXQgaXMNCiAgICAgICAg PGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgb2YgYW55IGhlbHAgaGVyZSkuDQogICAgICAgIDxi cj4NCiAgICAgICAgPGJyPg0KICAgICAgICAqIDMuMy4xOiAmcXVvdDtyZWNlaXZlZCB3aXRoIHRo ZSBBQ0smcXVvdDssICZxdW90O3NlbmRzIHBpZ2d5YmFja2VkIHJlc3BvbnNlJnF1b3Q7DQogICAg ICAgIGFyZSwNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYWdhaW4sIG92ZXJs eSBzcGVjaWZpYy4gJnF1b3Q7cmVjZWl2ZWQgaW4gdGhlIGxhc3QgcmVzcG9uc2UmcXVvdDsgYW5k DQogICAgICAgICZxdW90O3NlbmRzIGENCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJz cDsgcmVzcG9uc2UmcXVvdDsgY291bGQgd29yayBhcyByZXBsYWNlbWVudHMgZXZlbiBpZiBtZXNz YWdlIHR5cGVzDQogICAgICAgIGFyZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNw OyBwcmVzZWNyaXB0aXZlLg0KICAgICAgICA8YnI+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAg PC9ibG9ja3F1b3RlPg0KICAgIDxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtNDc3YmViYTctN2ZmZi04YTU5LTQ1 OTYtOWU1ZTk0YzAwYzZhIj5bQXV0aG9yc10gV2UgdXNlZCBSU1QgYXMgdGhlIGV4YW1wbGVzIG9m IHRoZSBDb0FQIFJGQyBzZWVtZWQgdG8gY29udmV5IHRoYXQgbWVhbmluZyB3aGVuIHRoZSBlbmRw b2ludCBpcyBub3QgaW4gYSBwb3NpdGlvbiB0byByZXNwb25kIHRvIHRoZSByZXF1ZXN0LCBidXQg dGhpcyBzZWVtcyB0byBiZSBhbiBlYXNpZXIgd2F5IHRvIGFjaGlldmUgdGhlIHNhbWUgZ29hbC4g QW5kIGFzIHlvdSBzYXksIGlmIHRoaXMgaXMgZWFzaWVyIG9uIGltcGxlbWVudGF0aW9ucyB3ZSBz aG91bGQgc3RyaXZlIGZvciB0aGF0LiA8L3NwYW4+PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+ DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2 YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQogICAgICAgIDxicj4NCiAgICAgICAgKiAzLjMuMTogJnF1b3Q7YWZ0ZXIgdGhlIG1h eGltdW0gcmV0cmFuc21pc3Npb24gYXR0ZW1wdHMsIHRoZSBDb0FQDQogICAgICAgIGNsaWVudA0K ICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyB3aWxsIHJlbW92ZSB0aGUgc3RhdGUg ZnJvbSBpdHMgc2lkZSZxdW90Oy4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAg ICZuYnNwOyZuYnNwOyBTbyB0aGUgZGV2aWNlIHRoYXQncyBiZWluZyBraWNrZWQgZnJvbSB0aGUg bmV0d29yayBjYW4gZGVsYXkNCiAgICAgICAgaXRzIG93bg0KICAgICAgICA8YnI+DQogICAgICAg ICZuYnNwOyZuYnNwOyBldmljdGlvbiBmb3IgYWJvdXQgYSBtaW51dGUgYXMgbG9uZyBhcyBpdCBk b2Vzbid0IGFuc3dlcj8NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICA8L2Jsb2Nr cXVvdGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAs IDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGln bjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBUaGlzIGlzIGFu IGludGVyZXN0aW5nIHVzZSBjYXNlLiBUbyBhdm9pZCB0aGlzLCB3ZSBtYXkgaGF2ZSB0byBjaGFu Z2UgdGhlIGJlaGF2aW91ciwgdG8gYSBOT04tbWVzc2FnZSBhbmQganVzdCByZW1vdmUgdGhlIHN0 YXRlLiA8L3NwYW4+PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2Zjlh ZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KiAzLjMuMjogSXMg cmVhdXRoZW50aWNhdGlvbiBhbHdheXMNCiAgICAgICAgdHJpZ2dlcmVkIGJ5IHRoZSBFQVAgcGVl ciwgb3IgY2FuIGl0DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGFsc28gYmUg dHJpZ2dlcmVkIGJ5IHRoZSBhdXRoZW50aWNhdG9yPyBJZiB0aGUgbGF0dGVyLCB3aWxsDQogICAg ICAgIHRoZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBhdXRoZW50aWNhdG9y IHVzZSAvLndlbGwta25vd24vYSBhZ2Fpbiwgb3IgUE9TVCBzb21ldGhpbmcgdG8NCiAgICAgICAg dGhlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHJlc291cmNlIGZyb20gd2hl cmUgaXQnZCBERUxFVEUgaW4gMy4zLjE/DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90 ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5lLWhlaWdo dDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3MtaW50ZXJu YWwtZ3VpZC04MzRlZjQ0Ni03ZmZmLTFiOGEtNDdlZS0yMDk5ZDI2ZWUyM2QiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdiKDAsIDAs IDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNhbC1hbGln bjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBUaGUgYW5zd2Vy IGlzIHllcywgRUFQIHBlZXIgYWx3YXlzIHRyaWdnZXJlZCB0aGUgcmUtYXV0aGVudGljYXRpb24s IGFzIGl0IGlzIHRoZSBvbmUgaW50ZXJlc3RlZCBpbiBtYWludGFpbmluZyBpdHMgbWVtYmVyc2hp cCB3aXRoaW4gdGhlIGRvbWFpbiwgb3IgZXZlbiBpdCBjb3VsZCBiZSBkb3JtYW50IGF0IHNvbWUg cG9pbnRzLiBBIHVzZSBjYXNlIGZvciB0aGVzZSBpcyBMb1JhV0FOIG5vZGVzLCB0aGF0IGhhdmUg dGhlIGNhcGFiaWxpdHkgb2Ygc3RhcnRpbmcgdGhlIGNvbW11bmljYXRpb24gcmVnYXJkbGVzcyBv ZiB0aGVpciBjbGFzcywgd2hlcmVhcyB0aGUgTmV0d29yayBzZXJ2ZXIgbWF5IG5vdCBzZW5kIGEg bWVzc2FnZSB1bnRpbCBpdCBoYXMgcmVjZWl2ZWQgc29tZXRoaW5nIGZyb20gdGhlIElvVCBkZXZp Y2UuIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpBcmlh bDtjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7Zm9udC13ZWlnaHQ6 NzAwO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7dGV4dC1kZWNvcmF0aW9u Om5vbmU7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlO3doaXRlLXNwYWNl OnByZS13cmFwOyI+DQo8L3NwYW4+PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkz ODZlN2I2ZjlhZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQog ICAgICAgIDxicj4NCiAgICAgICAgKiBjcnlwdG9zdWl0ZXM6IFdoYXQncyB0aGUgdXBncmFkZSBt b2RlbCBvZiB0aGF0IGhhcmRjb2RlZCBsaXN0Pw0KICAgICAgICBBcyBpdA0KICAgICAgICA8YnI+ DQogICAgICAgICZuYnNwOyZuYnNwOyBpcyBub3csIGl0IGxvb2tzIHByZXR0eSBzdGF0aWMsIHNv IHVwZGF0ZXMgd291bGQgYmUgdGhyb3VnaA0KICAgICAgICB1cGRhdGVzIG9mDQogICAgICAgIDxi cj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHRoaXMgZG9jdW1lbnQuIFRoZSBvYnZpb3VzIGFsdGVy bmF0aXZlIGlzIGFuIElBTkEgcmVnaXN0cnkNCiAgICAgICAgd2l0aA0KICAgICAgICA8YnI+DQog ICAgICAgICZuYnNwOyZuYnNwOyByYW5nZXMsIHBvbGljaWVzIGFuZCB0aGUgdXN1YWwgcHJvcyBh bmQgY29ucy4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNw OyBUaGVuIGFnYWluLCB0aGlzIGlzIG5vdCB0aGUgZmlyc3Qgbm9yIGxhc3QgdGltZSBBRUFEDQog ICAgICAgIGFsZ29yaXRobXMgd2l0aA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNw OyB0aGVpciBwYXJhbWV0cml6YXRpb24gYW5kIGhhc2ggZnVuY3Rpb25zIGFyZSBhc3NpZ25lZA0K ICAgICAgICBhZ2dyZWdhdGUNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgbnVt YmVycyAoSS1ELmlldGYtbGFrZS1lZGhvYyBjb21lcyB0byBtaW5kIHdoaWNoIGhhcw0KICAgICAg ICBhc3ltbWV0cmljIGFsZ3MNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgaW4g dGhlIG1peCB0b287IHByb2JhYmx5IG90aGVycyBhcyB3ZWxsKTsgY2FuIHdlIGRlZHVwbGljYXRl DQogICAgICAgIHRoaXMgd2l0aA0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBh bnl0aGluZz8gKFBvc3NpYmx5IGJ5IGJyaW5naW5nIHRoaXMgdXAgd2l0aCBDT1NFIG9yIE9TQ09S RQ0KICAgICAgICBwZW9wbGUpLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwv YmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAgIDxwIGRpcj0ibHRy IiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBw dDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtNTRjZDgzNTMtN2ZmZi1kZTY5LWVmOTAtMzRkZDA2 ZThlN2I0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5b QXV0aG9yc10gSW4gdGhlIG5leHQgdmVyc2lvbiB3ZSB3aWxsIHByb3Bvc2UgYSBzdHJ1Y3R1cmUg dG8gYWRkIGRpZmZlcmVudCBwYXJhbWV0ZXJzIHRvIHRoZSBDb0FQLUVBUCBleGNoYW5nZS4gV2l0 aGluIHRoZXNlIHBhcmFtZXRlcnMsIHdlIGNvbnNpZGVyZWQgdGhlIGV4dGVuc2liaWxpdHkgb2Yg dGhlIGNyeXB0byBzdWl0ZSBhbGdvcml0aG1zLjwvc3Bhbj48L3A+DQogICAgPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2Zjlh ZUB1bmlvdmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KiBPU0NPUkUgZGVy aXZhdGlvbjogSXMgaXQNCiAgICAgICAgY3J5cHRvZ3JhcGhpY2FsbHkgbmVjZXNzYXJ5IHRvIGRl cml2ZSAqYm90aCoNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgYSBtYXN0ZXIg c2VjcmV0IGFuZCBhIG1hc3RlciBzYWx0IHRocm91Z2ggS0RGPyAoU291bmRzIGxpa2UgYQ0KICAg ICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBuZWVkbGVzcyBzdGVwIHRvIG1lLCBhcyBi b3RoIG9ubHkgZ28gaW50byBLREYgb25jZSBtb3JlIHdoZW4NCiAgICAgICAgdGhlDQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGFjdHVhbCBPU0NPUkUgcGFyYW1ldGVycyBhcmUg ZGVyaXZlZCkuIEkgKmd1ZXNzKiB0aGVyZSdzIGENCiAgICAgICAgZ29vZCByZWFzb24NCiAgICAg ICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgd2h5IHRoZSBNU0sgaXMgbm90IHVzZWQgYXMg dGhlIE9TQ09SRSBJS00gcmlnaHQgYXdheSBhbmQgdGhlDQogICAgICAgIENTTyBhcw0KICAgICAg ICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyBPU0NPUkUgbWFzdGVyIHNhbHQsIGJ1dCBpdCdk IGhlbHAgdG8gaGF2ZSBhdCBsaXN0IGEgY29tbWVudA0KICAgICAgICBoZXJlIG9uDQogICAgICAg IDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IHdoeSB0aGF0J3MgbmVlZGVkLg0KICAgICAgICA8 YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IChJdCBtYXkgYmUgdXNlZnVs IHRvIGNvbXBhcmUgdGhpcyBzdGVwIHRvIHRoZSBIS0RGIHN0ZXBzIGluDQogICAgICAgIE9TQ09S RTsNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgdGhlaXIgaW5mbyBlbGVtZW50 IGlzIGFsd2F5cyBhIDUtZWxlbWVudCBhcnJheSB3aXRoIGEgNHRoDQogICAgICAgICZxdW90O3R5 cGUmcXVvdDsNCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgZWxlbWVudCBvZiAm cXVvdDtLZXkmcXVvdDsgb3IgJnF1b3Q7SVYmcXVvdDs7IG90aGVyIGV4dHJhY3Rpb25zIG1pZ2h0 IGp1c3QgaG9vaw0KICAgICAgICBpbiB0aGVyZQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNw OyZuYnNwOyB3aXRoIGRpZmZlcmVudCB0eXBlIHZhbHVlcywgbWF5YmUsIGFuZCBzYXZlIGV2ZXJ5 b25lIGFuIGV4dHJhDQogICAgICAgIGhhbmRsaW5nDQogICAgICAgIDxicj4NCiAgICAgICAgJm5i c3A7Jm5ic3A7IHN0ZXApLg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgIDwvYmxv Y2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHAgZGlyPSJsdHIiIHN0eWxlPSJsaW5l LWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0OyIgaWQ9ImRvY3Mt aW50ZXJuYWwtZ3VpZC02YWU3ZWMyMi03ZmZmLTQxNjMtYmRkNS00NGM1Yzg5YzUyNzIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogcmdi KDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB2ZXJ0aWNh bC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPltBdXRob3JzXSBZb3Ug YXJlIHJpZ2h0LCB0aGVyZSBzaG91bGQgYmUgYSBjbGFyaWZpY2F0aW9uIG9uIHdoeSB0aGlzIGlz IGRvbmUgdGhlIHdheSBpdCBpcy4gVGhlIG1haW4gcHVycG9zZSBpcyB0byB1c2UgTVNLJm5ic3A7 IGFzIHRoZSByb290IGtleSBmb3Iga2V5IGRlcml2YXRpb24uIEl0IGlzIGNvbW1vbiBwcmFjdGlj ZSB3aXRoIHRoZSB1c2FnZSBvZiB0aGUgTVNLLiBJZiBzYXkga2V5IHdlcmUgY29tcHJvbWlzZWQs IGFub3RoZXIgb25lIGNvdWxkIGJlIGRlcml2ZWQgZnJvbSB0aGUgTVNLLCB3aXRob3V0IGhhdmlu ZyB0byByZXNvcnQgdG8gYSBuZXcgYm9vdHN0cmFwcGluZyB0byByZWZyZXNoIHRoZSBNU0suPC9z cGFuPjwvcD4NCiAgICA8cD48YnI+DQogICAgPC9wPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNpdGU9Im1pZDpjOWNkYjIxNi01OWE3LWIwNmEtN2NkMC05Mzg2ZTdiNmY5YWVAdW5pb3Zp LmVzIj4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPiogT1NDT1JFIElEIGRlcml2YXRp b246DQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsgKiBS YW5kb21seSBhc3NpZ25lZCBmdWxsLWxlbmd0aCBpZGVhcyBsb29rIGxpa2UgYW4gb2RkDQogICAg ICAgIGNob2ljZS4gVGhleQ0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhcmUgZXhjZXNzaXZlbHkgbG9uZyAobm9uY2UgbGVuZ3RoIC0gNiBpcyA3IGZvciB0 aGUgTVRJDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFF Uy1DQ00tMTYtNjQtMTI4IGFuZCBzaG9ydGVyIGZvciBvdGhlciBjdXJyZW50IG9uZXMsIGJ1dCBJ DQogICAgICAgIGRvdWJ0DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRoYXQga2VlcGluZyB0aGUgSVYgKnNob3J0KiBpcyBuZWNlc3NhcmlseSBhIGRlc2ln bg0KICAgICAgICBjcml0ZXJpb24gZm9yDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGZ1dHVyZSBhbGdvcml0aG1zKS4NCiAgICAgICAgPGJyPg0KICAgICAg ICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaGF0IGNvbW1vbmx5IGhh cHBlbnMgaGVyZSAoZWcuIGluIHRoZSBBQ0UtT1NDT1JFIHByb2ZpbGUsDQogICAgICAgIG9yIGlu DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVESE9DKSBp cyB0aGF0IGVhY2ggcGFydHkgcGlja3MgYSByZWNpcGllbnQgSUQgb3V0IG9mIGl0cw0KICAgICAg ICBwb29sIG9mDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGN1cnJlbnRseSB1bnVzZWQgSURzLiBUaGlzIG1ha2VzIGZvciBzaG9ydGVyIGtleXMsIGFuZA0K ICAgICAgICBhbGxvd3MgdGhlDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGNsaWVudCB0byBiZSBzdXJlIHRoYXQgbm8gdHdvIHBlZXJzIHVzZSB0aGUgc2Ft ZSBjb250ZXh0Lg0KICAgICAgICA8YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEFueSBjaGFuY2Ugc29tZXRoaW5nIGxpa2UgdGhhdCBjYW4gc3RpbGwg bWFrZSBpdCBpbj8NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICA8L2Jsb2NrcXVv dGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWln aHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVy bmFsLWd1aWQtYjA3MDE4NjYtN2ZmZi1mN2MyLWViM2ItMGQyNTI5NTVlMjNhIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAw LCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxp Z246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5bQXV0aG9yc10gRGlkIG5vdCBz ZWUgdGhhdCBhcyByYW5kb20gYnV0IHBhcmFtZXRyaXNlZCBhY2NvcmRpbmcgdG8gdGhlIGNyeXB0 byBzdWl0ZS4gV2Ugd2lsbCB0cnkgdG8gbWFrZSB0aGlzIGFzIHN0cmFpZ2h0Zm9yd2FyZCBhcyBw b3NzaWJsZSBmb2xsb3dpbmcgeW91ciBjb21tZW50cy4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1j b2xvcjp0cmFuc3BhcmVudDtmb250LXdlaWdodDo3MDA7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12 YXJpYW50Om5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGlu ZTt3aGl0ZS1zcGFjZTpwcmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7Ij4NCjwvc3Bhbj48L3A+DQog ICAgPHA+PGJyPg0KICAgIDwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJt aWQ6YzljZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4mbmJzcDsmbmJzcDsgKiBJZiB0aGUgcGFydGllcyBo YXBwZW4gdG8gYmUgYXNzaWduZWQNCiAgICAgICAgdGhlIHNhbWUgc2VuZGVyIElELCBiYWQgdGhp bmdzDQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhcHBl biAoaWRlbnRpY2FsIGtleSBkZXJpdmF0aW9uLCBub25jZSByZXVzZSwgbnVjbGVhcg0KICAgICAg ICBtZWx0ZG93bikuDQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIGN1cnJlbnQgcGF0dGVybiBvZiBLREYnaW5nIElEcyBz dGFuZHMsIHRoaXMgbmVlZHMgdG8NCiAgICAgICAgYmUNCiAgICAgICAgPGJyPg0KICAgICAgICAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJldmVudGVkIGV4cGxpY2l0bHkuDQogICAgICAgIDxi cj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAg IDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJn aW4tYm90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtMjAxZjliNmQtN2ZmZi0zMGYy LWI4ZDEtZjRjMDE5OWQ0N2FjIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTog cHJlLXdyYXA7Ij5bQXV0aG9yc10gU2luY2UgdGhlIFNlbmRlciBhbmQgcmVjaXBpZW50IElEcywg YXJlIGRlcml2ZWQgZnJvbSB0aGUgTVNLLCB3aGljaCBpcyBhc3N1bWVkIHRvIGJlIGZyZXNoIGtl eSBtYXRlcmlhbCwgSSB0aGluayB0aGlzIHNob3VsZCBub3QgYmUgYSBwcm9ibGVtLiA8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAw MDAwMDtiYWNrZ3JvdW5kLWNvbG9yOnRyYW5zcGFyZW50O2ZvbnQtd2VpZ2h0OjcwMDtmb250LXN0 eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO3RleHQtZGVjb3JhdGlvbjpub25lO3ZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lO3doaXRlLXNwYWNlOnByZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcDsi Pg0KPC9zcGFuPjwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6Yzlj ZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5lcyI+DQogICAgICA8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgPGJyPg0KICAgICAgICAmbmJzcDsmbmJzcDsg KiBUaGUgZGVyaXZhdGlvbnMgb2YgJnF1b3Q7T1NDT1JFIFJFQ0lQSUVOVCBJRCZxdW90OyBhbmQg JnF1b3Q7T1NDT1JFIFNFTkRFUg0KICAgICAgICBJRCZxdW90OyBhcmUNCiAgICAgICAgPGJyPg0K ICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZnVzaW5nIGFzIHRoZXkgZWFjaCBu ZWVkIHRvIGhhcHBlbiBvbiBib3RoIHNpZGVzLCBhbmQNCiAgICAgICAgdGhlIHRlcm1zDQogICAg ICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpbGwgbWF0Y2ggb24g b25lIGFuZCBuZWVkIHRvIGJlIG9wcG9zaXRlIG9uIHRoZSBvdGhlci4NCiAgICAgICAgPGJyPg0K ICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoSSBjb3VsZG4n dCBldmVuIGVhc2lseSBmaW5kIHdoaWNoIGlzIGludGVuZGVkIHRvIGJlDQogICAgICAgIHdoaWNo KS4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBNeSBzdWdnZXN0aW9uIGlzIHRvIGRlcml2ZSAmcXVvdDtPU0NPUkUgRUFQIFBFRVIg U0VOREVSIElEJnF1b3Q7IGFuZA0KICAgICAgICAmcXVvdDtPU0NPUkUNCiAgICAgICAgPGJyPg0K ICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQVVUSEVOVElDQVRPUiBTRU5ERVIgSUQm cXVvdDsgaW5zdGVhZC4gKE9yIHByZWZlcmFibHkgc2hvcnRlcg0KICAgICAgICBzdHJpbmdzKS4N CiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgPC9i bG9ja3F1b3RlPg0KICAgIDxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtMzAy NmRiY2ItN2ZmZi01ZDEyLWE0ZTctOTg0NTlkZjllMTIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dy b3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5l OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5bQXV0aG9yc10gR29vZCBwb2ludCwgdGhhbmsgeW91 LiBXZSB3aWxsIGFkZHJlc3MgdGhpcyBhY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0aW9uLjwvc3Bh bj48L3A+DQogICAgPHA+PGJyPg0KICAgIDwvcD4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjaXRlPSJtaWQ6YzljZGIyMTYtNTlhNy1iMDZhLTdjZDAtOTM4NmU3YjZmOWFlQHVuaW92aS5l cyI+DQogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4qIEV4bWFwbGVzOiBEbyB5b3UgZW52 aXNpb24gcGFydGljdWxhciBFQVANCiAgICAgICAgcHJvdG9jb2xzIHRvIGJlIHVzZWQgaW4gdGhl DQogICAgICAgIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7IGdpdmVuIGV4YW1wbGVzPw0KICAg ICAgICA8YnI+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxw IGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4t Ym90dG9tOjBwdDsiIGlkPSJkb2NzLWludGVybmFsLWd1aWQtNDA1ODc1ZDYtN2ZmZi1jMzAxLTlh OGItNzViZmVlMzk4NTlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt aWx5OiBBcmlhbDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJl LXdyYXA7Ij5bQXV0aG9yc10gV2UgY29uc2lkZXIgdGhlIGV4YW1wbGVzIHRvIHVzZSBsaWdodHdl aWdodCBFQVAgbWV0aG9kcy4gVGhpcyBjb3VsZCBiZSBFQVAtUFNLIGZvciBpbnN0YW5jZS4gDQo8 L3NwYW4+PC9wPg0KICAgIDxwPjxicj4NCiAgICA8L3A+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2l0ZT0ibWlkOmM5Y2RiMjE2LTU5YTctYjA2YS03Y2QwLTkzODZlN2I2ZjlhZUB1bmlv dmkuZXMiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxicj4NCiAg ICAgICAgQmVzdCByZWdhcmRzDQogICAgICAgIDxicj4NCiAgICAgICAgQ2hyaXN0aWFuDQogICAg ICAgIDxicj4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogIDwvYm9k eT4NCjwvaHRtbD4NCg== --------------7CFFD4FA37F207B354D8AA67-- From nobody Mon Sep 27 10:19:00 2021 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801743A0D74 for ; Mon, 27 Sep 2021 10:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cablelabs.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 diVHSWCHjR9C for ; Mon, 27 Sep 2021 10:18:54 -0700 (PDT) Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08on2099.outbound.protection.outlook.com [40.107.100.99]) (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 ED9243A0D73 for ; Mon, 27 Sep 2021 10:18:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R4a6If0Xwg6RH29w75nEFcvJUyDXFjkr1YflcdMuv/TTcTCJQlZlAWBOJ5H+uEtR1gwXDQOcrjUainveAPyNEHncCtNe0MVukmmJwNFhxsnD5hdCLrKdrK+Ta/yy9w9bmGJt6IVLkt43hmkfP4+q0c8tTWzEjrfRbn3+caKiZVg5nF0OUZ13Xiwa3VrQM2YDuBDYCcJGSVt2Y4uZVkXyoWNDDHbJmL3dTBwJXNVnP6K+ZEPwSmsnvIaaCHZkn3pNvFxKaQF4eW4eP3qosgRJUqFv/oaQf95TEBupfOY3zjTzdk1Jfsj3dUZUpsl4nxNY0OWAjOq1qm1pmX1oEV/yXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mxy8uttGo1RxfCDu6H7Ob1oxoqwXzv7V2F8AqzFbHuw=; b=Kv7xBypzO1nG0GXMlP7ZPZtQiedVPhdZkjOAtYeTnki1RUBZrsjGgYJ831u9C++b6X5WkEJCzNloP/BO7drSUqMiFTYfpmRIZAL4fRN5CkyNdjhdrFkiiUzIJfZSdHg2jQGrfZE6YboOD26KP1tHuZJkqvsZfCxE8grAoqNEHl3xNaGjWcOOCvtoAqEG56MT60CZyWiHsZMy23UwnWXeTNns/DZ65J/0rh0V0eZ0Zn1F+tgq7jX8v6milOmkLqPINxa0Btzeu9k4O1u/i5iqOgNzYNByYJsqLKekqvGp7YpWkwJVBVQR3V5FuyQO1jAYD+5G5JBbU5S7CGoclNXuyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mxy8uttGo1RxfCDu6H7Ob1oxoqwXzv7V2F8AqzFbHuw=; b=bZ/oUbkN/ahChoPxTb1H8zBZmz2v7wgZongB/REC0tM5UzYUAvCrZdvqxJrTlUwLiZwmTQ/tcR8MDJlgQRASakDE3I7IoNFJymcwgNnAyIBhukIF9vcn+SlFzTKFcYkX4qfL7CwH5Rdl2j+I/QeULxmrXzKpkkCdK74xej0EiS7dZK1UpwdWMDMAZCWbJ22HQD0kYCVvPfrlZhkHKcSYi6/duUeTdrtBoIo8OIeLBMtj2SpBaEw0GyUXNpO691MuBIf29FiuUEbin9ixZJGigBg/83qE6Oi+Lpx429SSgQlMO3i/0bvebwy6FGGDvlygIoh8oB3U0pcANHl4JkEoLg== Received: from CY4PR06MB3367.namprd06.prod.outlook.com (2603:10b6:910:5a::18) by CY4PR06MB2917.namprd06.prod.outlook.com (2603:10b6:903:138::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.15; Mon, 27 Sep 2021 17:18:49 +0000 Received: from CY4PR06MB3367.namprd06.prod.outlook.com ([fe80::1d89:a256:5f46:fbcb]) by CY4PR06MB3367.namprd06.prod.outlook.com ([fe80::1d89:a256:5f46:fbcb%4]) with mapi id 15.20.4544.021; Mon, 27 Sep 2021 17:18:49 +0000 From: Yuan Tian To: "Emu@ietf.org" Thread-Topic: Question of piggybacking in EAP Thread-Index: AdezuIE1FVKSqB0MTF6lmvsYrrZUmg== Date: Mon, 27 Sep 2021 17:18:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cablelabs.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54fd8867-8a36-44bc-6d82-08d981dadee4 x-ms-traffictypediagnostic: CY4PR06MB2917: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Nb2V/FKeOQQ7Lc1x7u+8SiG7jWrIQDoFGV+hk0kqw+qWfcjFxGzwrScLLnWZ+Ox3LlUkp96tH9SVb0WrbyWyXAafoJ4ttkhZNBLeZ+u+mrs9Y90tU5ukRZGBTbmdDMBQuhpKgi+7V3skwXR3zqTLPPhPwAOxEYrn/7pjKrRYbE2ry4DVPfNT4j7rgX5+eUqFzd250/qOfAtJc6F8itJ+mIqnjfeGVYu9p+pGR5/36C75HfxdOtNKkMBGGuA0laikcYYywflXtlgXoMXSouhSe2TLwYXqgbsx6SUN+zbu734XEB3xN2La7ro85rfNwl5oT+kqS793zyzqQ2lZfN1kDcIPLHaY10GR0W7UMishN2whIDrR+GJD5YLOjIcphggf1RRvERWG66Uz0+75GUw769rPBuw8zitZmQXBPcx/RQryqyXJCStjU5hiXP77TisdjQkP2z/3ZsJx02ub9736gmAQGA/LnbwzOBlp6QT4FBDzobq6fT8Z8h77PKIOC7p0H8fOQSIy3Co75Mt/0TQOaj4cmzjSjnQq+LbozW0CbmQM6jqRIt0idfax1ND6xbOdFMf+I2VCFoMCZpEmmN0ZP8sOTIOOAWEhZXYF/HCOMSZ7HQQlPioOY4zsZdLaFfiHIy/ltWRDRwHyal1q7QfPUH4MB0sM3N/f6jid0IZChHr5fd0RB0pMRBz62KSIyiRoL4py2qR9L8ZJSVkVNlvseQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR06MB3367.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(76116006)(33656002)(508600001)(186003)(8676002)(86362001)(83380400001)(6916009)(6506007)(5660300002)(66556008)(64756008)(66476007)(316002)(38070700005)(2906002)(55016002)(66946007)(8936002)(122000001)(38100700002)(9686003)(71200400001)(7696005)(52536014)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?YQ4rlXHikzUQpGC/v99gBqYBqKLEw7jljEs/aMsXr33slVij/VF8SuU0GvVc?= =?us-ascii?Q?BNcKc444ftrrVl0QpMXj1pHEdDyZd5eToxrwms/pjK29DW4LSi4RoZFMtm7K?= =?us-ascii?Q?5YA27APf79DVXws/OJAr/BvbcQmNtvE1aB0XZ2lasgUUPdBYX9397LI3CdFh?= =?us-ascii?Q?OsLXBi5tOZYD8ojm1zbl/CXeXUI5/IJ+6PYhPnnP+Mit/sLaRjHfHzTvybmE?= =?us-ascii?Q?fHTnpurnsDrPJikSPp0cdbrqKcb+BDzJlaij/yaxhadQvUtZ379kENt40Tk5?= =?us-ascii?Q?m8GyNLhUbvMztF/sY9dv3JWNQLYOTuTHsBvye4G/WqlBYF7U4Ll7168LlzbX?= =?us-ascii?Q?j/xUvRn4V/nDfbA2lKNMR0ImBu5Y/7FbXflc+FvUdXSoqBFINMYLzLb970J+?= =?us-ascii?Q?jRHJP/90720t4iZJafuPNRNzaHiU/dmeRDMSp8NvAfpC0bFdgUKypiwtMb4f?= =?us-ascii?Q?NjYeo9GDbvBa6VWSNlbUJr2Cn0fksXMJjZnKZ5/sf/vldq1cORDjxV/bUsj+?= =?us-ascii?Q?ie8ZQ/EcJQ6S5W1IyKBE2UleHsMcRK6isV1SW1mBSVQ+pU8p4snwsA2aT7sw?= =?us-ascii?Q?2zj8ODKqb9j88mvBvgyNJJO6PEpcnsSTLNdGw/hkhxaginQmoowIVMpWEwkW?= =?us-ascii?Q?6AYGCo2KPJuBo/ZaCw9k41h7xwmwWd2t7k1hSucor+6WUFXn7KnB95lfA2kn?= =?us-ascii?Q?3jpTptSkQfJ80a1VBjEWIgFKEZLcjKDaAbXae4p1P7qBHQS62tbkTuXuoX1l?= =?us-ascii?Q?B12ntFq4DaApoARrSxzhyXreso5FqZC7IhGRs8FV1HJsJJF1Ag7rHXWcpltQ?= =?us-ascii?Q?1roEHXCRAk6kug7lKMAHyf/KCm8ECitDa6/8jyglDmKUsk5+bsIf0TeLQTpn?= =?us-ascii?Q?FKnHqA8RFPRjVh6ICfbxDfpKon1XY+lMpNyEPn3lwTEMpU9mRFNY/iCd6HF0?= =?us-ascii?Q?lISPq2q00e6njWCzAPUROhHe8DRSWSfyQ7E9oDS13zLixh9uFsxEy4Q1uhHz?= =?us-ascii?Q?6j1qizCPODn9s2VbwGTJz2PFbH0MmWFhN7dYCG2n6g22gZjfjGKZrrbrtk+4?= =?us-ascii?Q?26pq5HmTJGBK6L1nMiZmVjxskzeyebd+6PCmfailCDZCgZp2pmGJMP77j3nf?= =?us-ascii?Q?jKaKXiZIjwv1d4WU+QkhW4CpiJhqoEku6wcjGaiv+sR8fLazcmQ22bTbTiu2?= =?us-ascii?Q?4uiu/5MiYchg9MwWrNDohsKGpYaeIoGbS9yG2p2UgEFpS633beQtX26lbg0W?= =?us-ascii?Q?DXtKZer4TvQs2ACd/XvRPv4lO94GgpzppXyLRc8+SYkwNP3wBm3faYJCwMtn?= =?us-ascii?Q?Bc+KtZJSSsAi+P9AOFssDeScOiWvh6SdGsGaBTR7CLhEEsBBydruVX3jt+gl?= =?us-ascii?Q?TnKVShsc3Qmz9USmMxu/79jVmqkw?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR06MB336784C5CB00416DA13B5D9A85A79CY4PR06MB3367namp_" MIME-Version: 1.0 X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR06MB3367.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54fd8867-8a36-44bc-6d82-08d981dadee4 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2021 17:18:49.0762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kCxVya1ee3XnqcabCakA/sAR0l300x6UaBmaov4sW28jFSieIds6tk61cMzcpzHf4nMB5IVWywEksnE277n/UA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2917 Archived-At: Subject: [Emu] Question of piggybacking in EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2021 17:18:59 -0000 --_000_CY4PR06MB336784C5CB00416DA13B5D9A85A79CY4PR06MB3367namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have a question related to the piggybacking in EAP and was wondering if I= could get your guidance here: I was working on a demo to demonstrate my customized protocol. I was hoping to use the EAP method as phase 1 to build a secured channel us= ing TLS handshake (like EAP-TTLS) and then implement my own protocol as the= phase 2 method. I have checked some RFCs and noticed that both EAP-TEAP and EAP-TTLS seem t= o be good choices here. As to EAP-TEAP, it uses a TLS handshake to establish a secured tunnel and i= n phase 2, it has EAP-Payload to allow you to encapsulate your protocol. The problem is, it seems EAP-TEAP hasn't been widely supported yet, at leas= t not in HostApd. As to EAP-TTLS, in RFC 5281 Section 7.4, it says Such "piggybacking" occurs when the party that completes the handshake also has AVPs to send. For example, when negotiating a resumed TLS session, the TTLS server sends its ChangeCipherSpec and Finished messages first, then the client sends its own ChangeCipherSpec and Finished messages to conclude the handshake. If the client has authentication or other AVPs to send to the TTLS server, it MUST tunnel those AVPs within the same EAP-TTLS packet immediately following its Finished message. If the client fails to do this, the TTLS server will incorrectly assume that the client has no AVPs to send, and the outcome of the negotiation could be affected. And I checked AVP lists, there is an "EAP" AVP available and but it seems t= o be designed for AAA and needs to be always used with RADIUS access-reques= t/access-challenge (is that okay if I do not allow the server to forwards t= he message in Radius access-request?). Upon receipt of the tunneled EAP-Response/Identity, the TTLS server forwards it to the AAA/H in a RADIUS Access-Request. So my question is, besides EAP-TTLS, is there an EAP protocol that is widel= y supported and can be used for piggybacking a customized protocol? Thanks,. Yuan --_000_CY4PR06MB336784C5CB00416DA13B5D9A85A79CY4PR06MB3367namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I have a question related to the piggybacking in EAP= and was wondering if I could get your guidance here:

 

I was working on a demo to demonstrate my customized= protocol.

I was hoping to use the EAP method as phase 1 to bui= ld a secured channel using TLS handshake (like EAP-TTLS) and then implement= my own protocol as the phase 2 method.

I have checked some RFCs and noticed that both EAP-T= EAP and EAP-TTLS seem to be good choices here.

 

As to EAP-TEAP, it uses a TLS handshake to establish= a secured tunnel and in phase 2, it has EAP-Payload to allow you to encaps= ulate your protocol.

The problem is, it seems EAP-TEAP hasn’t been = widely supported yet, at least not in HostApd.

 

As to EAP-TTLS, in RFC 5281 Section 7.4, it says

 

Such "piggybacking" occurs when the party = that completes the

   handshake also has AVPs to send.  = For example, when negotiating a

   resumed TLS session, the TTLS server se= nds its ChangeCipherSpec and

   Finished messages first, then the clien= t sends its own

   ChangeCipherSpec and Finished messages = to conclude the handshake.  If

   the client has authentication or oth= er AVPs to send to the TTLS

   server, it MUST tunnel those AVPs wi= thin the same EAP-TTLS packet

   immediately following its Finished m= essage.  If the client fails to

   do this, the TTLS server will incorrect= ly assume that the client has

   no AVPs to send, and the outcome of the= negotiation could be

   affected.

 

And I checked AVP lists, there is an “EAP̶= 1; AVP available and but it seems to be designed for AAA and needs to be al= ways used with RADIUS access-request/access-challenge (is that okay if I do= not allow the server to forwards the message in Radius access-request?).

   Upon receipt of the tunneled EAP-R= esponse/Identity, the TTLS server

   forwards it to the AAA/H in a RADIUS Ac= cess-Request.

 

So my question is, besides EAP-TTLS, is there an EAP= protocol that is widely supported and can be used for piggybacking a custo= mized protocol?

Thanks,.

 

Yuan

 

 

--_000_CY4PR06MB336784C5CB00416DA13B5D9A85A79CY4PR06MB3367namp_-- From nobody Mon Sep 27 10:29:25 2021 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB033A0E0E for ; Mon, 27 Sep 2021 10:29:23 -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, SPF_HELO_NONE=0.001, 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 88c6y_TTBPE5 for ; Mon, 27 Sep 2021 10:29:18 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4C03A0E0B for ; Mon, 27 Sep 2021 10:29:17 -0700 (PDT) Received: from [192.168.20.33] (unknown [75.98.136.133]) by mail.networkradius.com (Postfix) with ESMTPSA id D96F84F; Mon, 27 Sep 2021 17:29:14 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Alan DeKok In-Reply-To: Date: Mon, 27 Sep 2021 13:29:13 -0400 Cc: "Emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yuan Tian X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Emu] Question of piggybacking in EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2021 17:29:23 -0000 On Sep 27, 2021, at 1:18 PM, Yuan Tian wrote: > And I checked AVP lists, there is an =E2=80=9CEAP=E2=80=9D AVP = available and but it seems to be designed for AAA and needs to be always = used with RADIUS access-request/access-challenge (is that okay if I do = not allow the server to forwards the message in Radius access-request?). RFC 5281 Section 10 says that the inner data is in Diameter format, = and uses the RADIUS / Diameter attribute space. So just use = EAP-Message. > Upon receipt of the tunneled EAP-Response/Identity, the TTLS server > forwards it to the AAA/H in a RADIUS Access-Request. > =20 > So my question is, besides EAP-TTLS, is there an EAP protocol that is = widely supported and can be used for piggybacking a customized protocol? > Thanks,. TTLS seems like the best approach. Inside of that you can use = EAP-Message, and a vendor-specific EAP type. Alan DeKok. From nobody Wed Sep 29 08:06:20 2021 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E7B3A19B8 for ; Wed, 29 Sep 2021 08:06:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20210112.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 Jj8Dsuy93JVc for ; Wed, 29 Sep 2021 08:06:18 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 EA35E3A1ABB for ; Wed, 29 Sep 2021 08:06:17 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id i19so9144800lfu.0 for ; Wed, 29 Sep 2021 08:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=7/6g9nQv3uf3pnD4DW22tzBWIDglvEmpzSq9cNYuKHc=; b=mHkuF1GdWoOBJC429yuvs+im1HcXTUa21ihgNMDmOVXBIGbzVnHYtehgaEoRHxh+SX aWEmAe29UdGV5u3d/wOtKUBxuMsg7Z47VyXvFBtPHVRF5a1zsLdS5xQPQDzQMQnlyTR4 SGyOUY8RpANx7/tTZ4uoPM+H0LAndv9Exc2ajgQip5SHKtfJV2Z+jysqwu2DG44d3k7Y 9apG8LqOc9RK8JZfcXtaHuJA8fM9MoDYjPEMi/kAVIKylHm9D1SEwjYY2ph6AL1P9L5k NMm7kCgKIJgej8OI9q+QYMENh5bQcbhQkJjRtTj+fZjWCv/OFuJC1i9smN5DDKV+j8yt eQxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7/6g9nQv3uf3pnD4DW22tzBWIDglvEmpzSq9cNYuKHc=; b=CJu8mWHFZUVBki/1qH0bNpl0ikH9aZZt0V/cN5zjGT+jIfjnCh+mOfleqs2CuEd36i gXIajceuWaK7dUH3CU2zKllulcFBTisnnCO62SUjyChXauw02MRniGJGH8MEjujm0i33 hwH/gZzkh+ax8R4xvK7yioKP01XsHiSjijrjaiZKfwU189biWD5Ag357gVHTGoFfO+R0 jMMePwfdmDB+VD6BHs4PpIo9a3Znr3CyVeZnd/s2zoGan6aTnQmLMI+OIwJGO4rrPVVr MTZ7zq992tGfK0DmQfE1nJM4D37PgZ1rx4q/JdE42+Ur1qGPAVsPeF97xWaCPgrEofQN P50w== X-Gm-Message-State: AOAM531d/icddswEMTwDcqYqO3fq+6slk8auzsV3nrN1mN3cvTop5IMM Bq+SQvwa2+1EaQ1IEEBjDjOJ9cZt41snB+Z8YRhYb8fJYwITVw== X-Google-Smtp-Source: ABdhPJyaVy9bFcxLn1t1qwHZ9ESHOP7LHGMaGH11KKSWUzz32lX8sXy2VPI/o1XCKA5qXD8oQ+QaxZ9C1WxBY0RFupM= X-Received: by 2002:ac2:55a9:: with SMTP id y9mr168128lfg.63.1632927973417; Wed, 29 Sep 2021 08:06:13 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Wed, 29 Sep 2021 08:06:02 -0700 Message-ID: To: EMU WG Content-Type: multipart/alternative; boundary="000000000000ccb89405cd23abe6" Archived-At: Subject: [Emu] EMU Meetings X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 15:06:20 -0000 --000000000000ccb89405cd23abe6 Content-Type: text/plain; charset="UTF-8" Mohit and I discussed some options for meetings this year. We think it would be better not to meet at IETF 112 and instead schedule some focused virtual interim meetings where we can address specific issues. These interims will most likely take place after IETF 112. If you have a topic you would like to cover at an interim please let us know. Thanks, The chairs --000000000000ccb89405cd23abe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mohit and I discussed some options for meetings this = year.=C2=A0 We think it would be better not to meet at IETF 112 and instead= schedule=C2=A0some focused=C2=A0virtual interim meetings where we can addr= ess specific issues.=C2=A0 These interims=C2=A0will most likely take place = after IETF 112. If you have a topic you would like to cover at an interim p= lease let us know.=C2=A0=C2=A0

Thanks,
<= br>
The chairs
--000000000000ccb89405cd23abe6-- From nobody Thu Sep 30 05:23:03 2021 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A066C3A0B26; Thu, 30 Sep 2021 05:22:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-emu-eap-tls13@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey , joe@salowey.net X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <163300455762.6020.7934912747983319097@ietfa.amsl.com> Date: Thu, 30 Sep 2021 05:22:37 -0700 Archived-At: Subject: [Emu] Lars Eggert's No Objection on draft-ietf-emu-eap-tls13-20: (with COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2021 12:22:38 -0000 Lars Eggert has entered the following ballot position for draft-ietf-emu-eap-tls13-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.1.4. , paragraph 4, nit: - server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and - no data from the EAP-TLS peer, follwed by EAP-Success from the + server, followed by an EAP-Response packet of EAP-Type=EAP-TLS and + + + no data from the EAP-TLS peer, followed by EAP-Success from the + + Section 2.1. , paragraph 5, nit: > t encrypt significant amounts of data so this functionality is not needed. I > ^^^ Use a comma before "so" if it connects two independent clauses (unless they are closely connected and short). Section 2.1.7. , paragraph 3, nit: > ods can use the TLS exporter in a similar fashion, see [I-D.ietf-emu-tls-eap- > ^^^^^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. Section 2.1.7. , paragraph 3, nit: > o truncate the output by requesting less data from the TLS-Exporter function > ^^^^ Did you mean "fewer"? The noun data is countable. Section 2.2. , paragraph 5, nit: > in EAP-TLS with TLS 1.3 is stronger as authentication with revoked certific > ^^ Comparison requires "than", not "then" nor "as". Section 2.5. , paragraph 2, nit: > ovide integrity and replay protection but MAY be unauthenticated. Protected f > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). Section 2.5. , paragraph 6, nit: > dresses, IP addresses, port numbers, WiFi SSID, etc.). EAP-TLS servers implem > ^^^^ Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi Alliance.). Section 4. , paragraph 4, nit: > layer. To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS > ^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "securely" to avoid wordiness. Section 5.1. , paragraph 5, nit: > e the session ID or PSK identity to lookup this information during resumption > ^^^^^^ The word "lookup" is a noun. The verb is spelled with a white space. Section 5.1. , paragraph 6, nit: > ached data cannot be retrieved in a secure way, resumption MUST NOT be done. > ^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "securely" to avoid wordiness. Section 5.4. , paragraph 1, nit: > e without access to cached data. Therefore systems which expect to perform a > ^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Therefore". Section 5.4. , paragraph 6, nit: > do not contain any cleartext privacy sensitive information. Tracking of use > ^^^^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 5.5. , paragraph 3, nit: > typically visible. How much privacy sensitive information the domain name l > ^^^^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 5.6. , paragraph 3, nit: > a cryptographically secure way so that that it is computationally infeasible > ^^^^^^^^^ Possible typo: you repeated a word. Reference [RFC2560] to RFC2560, which was obsoleted by RFC6960 (this may be on purpose). Reference [RFC4282] to RFC4282, which was obsoleted by RFC7542 (this may be on purpose). Reference [RFC4346] to RFC4346, which was obsoleted by RFC5246 (this may be on purpose). Reference [RFC2246] to RFC2246, which was obsoleted by RFC4346 (this may be on purpose). Reference [RFC5077] to RFC5077, which was obsoleted by RFC8446 (this may be on purpose). Reference [RFC5246] to RFC5246, which was obsoleted by RFC8446 (this may be on purpose). Reference [RFC3280] to RFC3280, which was obsoleted by RFC5280 (this may be on purpose). Document references draft-ietf-tls-md5-sha1-deprecate-08, but -09 is the latest available revision.