From nobody Mon May 6 03:47:46 2019 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 4DE211200BA for ; Mon, 6 May 2019 03:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 myD7lRmM6TzP for ; Mon, 6 May 2019 03:47:42 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC57120059 for ; Mon, 6 May 2019 03:47:40 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.13.8) with ESMTP id x46AlKk3003257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 May 2019 16:17:20 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id x46Al6b0009426; Mon, 6 May 2019 16:17:09 +0530 X-AuthUser: anoop Received: from DESKTOPV9MK6VP ([223.31.121.170]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id x46Al44Z014013; Mon, 6 May 2019 16:17:04 +0530 From: "Anoop Kumar Pandey" To: Date: Mon, 6 May 2019 16:17:01 +0530 Message-ID: <009e01d503f9$0a9848f0$1fc8dad0$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01D50427.2451BD70" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdUD9TDpPh9cnjiSTGGx5WQgI53wxA== Content-Language: en-in X-CDAC-PUNE-MailScanner-ID: x46Al6b0009426 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.188, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, T_KAM_HTML_FONT_INVALID 0.01, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-5.299, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_00 -3.50, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: x46AlKk3003257 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: [Emu] Review of draft draft-ms-emu-eaptlscert-02 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, 06 May 2019 10:47:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009F_01D50427.2451BD70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Draft Review (draft-ms-emu-eaptlscert-02) Title: Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods URL: https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02 Description: The draft talks about large TLS certificates with long certificate chains. This may result in fragmentation into smaller packet as EAP fragment size is typically is just 1000-1500 bytes. The fragmentations could cause latency and in some cases EAP authenticator implementations may drop the EAP session after 40-50 packets. The draft gives an overview of methods and tools for overcoming the deployment challenges induced by large certificates. Review: Section 3 talks about various reasons for a certificate being large. Subject Alternative Name field is typically used for multi-domain or wildcard certificates (fb.com, *.facebook.om, facebook.net, messenger.com) where all domains are protected by same certificate. I doubt that SAN will be a reason in IoT world for larger certificate. Similarly key size and signature field is in bits (e.g. 2048 bit key, 2048 bit signature, 224 bit key if ECC is used). So this also shouldn't contribute to a larger certificate. The same can be said about OID and user groups. Key usage is limited to digital signature (80) [just one usage] in an end device certificate. Section 4.1 claims RSA key sizes and digital signature size to be 384 bytes which is wrong. The RSA key size is 1K to 4K (1024 bit to 4096 bit) practically and corresponding ECC key will range from 160 bits to 256 bits. The size mentioned by the authors is the size of the entire certificate. Authors may refer ( https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptogra phy-standards/documents/presentations/session2-ford-warwick.pdf) for further optimizations pertaining to ECC adoption. Section 4.1.1 talks about shortening or avoid certain fields in the certificate. Mostly the changes are marginal and the authors have not presented quantitatively, how much saving in certificate size could be achieved with it and will it be sufficient. Section 4.2.1 talks about pre-distributing and omitting CA certificate. It will require constant update of CA certificates whenever new CAs are licensed or license of existing CA is revoked. Large chain validation can be avoided by using cross CA validation also instead of hierarchical validation. A common certificate repository (like Google Certificate Transparency https://transparencyreport.google.com/https/certificates?hl=en) could also be used and chain validation may not be required in this case. Section 4.2.2 will only work if at least one successful authentication has occurred. If any certificate change happens (expiry, revocation, key change), then again this method will fail. Section 4.2.3 talks about compressing the certificate. This is achievable, however the capability to compress, decompress and performing ECC certificate validation within a small IoT device is questionable. P.S: In EAP-TLS, isn't there clear direction on how many packets exchange are allowed before dropping EAP session. Why do some implementations drop session after 40-50 packets itself? In the standard of EAP-TLS, can the no. of exchange packets be increased? If yes, apart from latency, what other impact could it have? Regards, Anoop Kumar Pandey Principal Technical Officer C-DAC Bangalore India ------------------------------------------------------------------------------------------------------------ [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------ ------=_NextPart_000_009F_01D50427.2451BD70 Content-type: multipart/related; boundary="----------=_1557139638-19512-2" This is a multi-part message in MIME format... ------------=_1557139638-19512-2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft Review (draft-ms-emu-eapt= lscert-02)
Title: Handling Large Certificates and Long Certificate Chain= s in TLS-based EAP Methods
URL: https://tools.ietf.org/html/draft-ms-emu= -eaptlscert-02


Descrip= tion:
The draft talks about large TLS certificates with long certificat= e chains. This may result in fragmentation into smaller packet as EAP fragm= ent size is typically is just 1000-1500 bytes. The fragmentations could cau= se latency and in some cases EAP authenticator implementations may drop the= EAP session after 40-50 packets. The draft gives an overview of methods an= d tools for overcoming the deployment challenges induced by large certifica= tes.


Review:

Section 3 talks about various reas= ons for a certificate being large. Subject Alternative Name field is typica= lly used for multi-domain or wildcard certificates (fb.com, *.facebook.om, = facebook.net, messenger.com) where all domains are protected by same certif= icate. I doubt that SAN will be a reason in IoT world for larger certificat= e.

= Similarly key size and = signature field is in bits (e.g. 2048 bit key, 2048 bit signature, 224 bit = key if ECC is used). So this also shouldn’t contribute to a larger ce= rtificate.

The same can be = said about OID and user groups. Key usage is limited to digital signature (= 80) [just one usage] in an end device certificate.  =

 

Section 4.1 claims RSA key sizes and digital signature size to b= e 384 bytes which is wrong. The RSA key size is 1K to 4K (1024 bit to 4096 = bit) practically and corresponding ECC key will range from 160 bits to 256 = bits. The size mentioned by the authors is the size of the entire certifica= te. Authors may refer (https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryp= tography-standards/documents/presentations/session2-ford-warwick.pdf= ) for further optimizations pertaining to ECC adoption.


Section 4.1.1 talks about shortening = or avoid certain fields in the certificate. Mostly the changes are marginal= and the authors have not presented quantitatively, how much saving in cert= ificate size could be achieved with it and will it be sufficient.


Section 4.2.1 talks about pre-= distributing and omitting CA certificate. It will require constant update o= f CA certificates whenever new CAs are licensed or license of existing CA i= s revoked. Large chain validation can be avoided by using cross CA validati= on also instead of hierarchical validation. A common certificate repository= (like Google Certificate Transparency https://transparencyreport.google.com/https/certificate= s?hl=3Den) could also be used and chain validation may not be re= quired in this case.


S= ection 4.2.2 will only work if at least one successful authentication has o= ccurred. If any certificate change happens (expiry, revocation, key change)= , then again this method will fail.

 

P.S: = In EAP-TLS, isn’t there clear direction on how many packets exchange = are allowed before dropping EAP session. Why do some implementations drop s= ession after 40-50 packets itself?

In the standard of E= AP-TLS, can the no. of exchange packets be increased? If yes, apart from la= tency, what other impact could it have?

 

 

Regards,

Anoop Kuma= r Pandey

Principal Technical Officer

= C-DAC Bangalore

India


---------------------------------------------------------------------= ---------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= --------------------------------------- ------------=_1557139638-19512-2 Content-Type: image/jpeg; name="signature.jpg" Content-Disposition: inline; filename="signature.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/4QCKRXhpZgAATU0AKgAAAAgABwEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAQAAAAclEQ AAEAAAABAQAAAFERAAQAAAABAAAAAFESAAQAAAABAAAAAAAAAAAAAABgAAAA AQAAAGAAAAABcGFpbnQubmV0IDQuMS4xAP/bAEMADQkKCwoIDQsLCw8ODRAU IRUUEhIUKB0eGCEwKjIxLyouLTQ7S0A0OEc5LS5CWUJHTlBUVVQzP11jXFJi S1NUUf/bAEMBDg8PFBEUJxUVJ1E2LjZRUVFRUVFRUVFRUVFRUVFRUVFRUVFR UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUf/AABEIAL4BCgMBIgACEQED EQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMD AgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQz YnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdo aWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6 wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQAD AQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAAB AncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AOc8 E+D4/FEV273rW32dlACx7s5z7j0rp/8AhUkH/QZk/wC/A/8AiqPg1/x66r/v x/yavSqAPNf+FSQf9BmT/vwP/iqP+FSQf9BmT/vwP/iq9KooA81/4VJB/wBB mT/vwP8A4qj/AIVJB/0GZP8AvwP/AIqvSqKAPNf+FSQf9BmT/vwP/iqP+FSQ f9BmT/vwP/iq9KooA81/4VJB/wBBmT/vwP8A4qj/AIVJB/0GZP8AvwP/AIqv SqKAPNf+FSQf9BmT/vwP/iqP+FSQf9BmT/vwP/iq9KooA81/4VJB/wBBmT/v wP8A4qj/AIVJB/0GZP8AvwP/AIqvSqKAPNf+FSQf9BmT/vwP/iqP+FSQf9Bm T/vwP/iq9KooA81/4VJB/wBBmT/vwP8A4qj/AIVJB/0GZP8AvwP/AIqvSqKA PNf+FSQf9BmT/vwP/iqP+FSQf9BmT/vwP/iq9KooA81/4VJB/wBBmT/vwP8A 4qj/AIVJB/0GZP8AvwP/AIqvSqKAPNf+FSQf9BmT/vwP/iqP+FSQf9BmT/vw P/iq9KooA81/4VJB/wBBmT/vwP8A4qj/AIVJB/0GZP8AvwP/AIqvSqKAPNf+ FSQf9BmT/vwP/iqP+FSQf9BmT/vwP/iq9KooA81/4VJB/wBBmT/vwP8A4qj/ AIVJB/0GZP8AvwP/AIqvSqKAPNf+FSQf9BmT/vwP/iqP+FSQf9BmT/vwP/iq 9KooA8j8RfDiHRdCutSXVHmMCg7DCBnJA65968+r3v4g/wDIkan/ALi/+hrX glAHqfwa/wCPXVf9+P8Ak1elV5r8Gv8Aj11X/fj/AJNXpVABRRRQAUUUUAFF FFABRQSB1OKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooA534g/wDIkan/ALi/+hrXgle9/EH/AJEjU/8AcX/0Na8EoA9T +DX/AB66r/vx/wAmr0qvNfg1/wAeuq/78f8AJq9KoAKKKKACiiigApkk0UWP NkRM9NzAZqOa42SCGJPMmIztzgKPUntTYrX52luGEsrDb935VHoBSv2HbuQW qW15ukmMc8p+bax3BFzxgduKkVPsdxGiZ8iUlQmfuNjPHscHiqMcK2dtKDN5 VzBudXlICkH37qfzH5VNYTzXtyryiN44lyskbfKWIHb1wT/npCf3lNGpRQSA Mk4FFaEBRRRQAUUUUAFFFFABRRRQAUUVDd3UFlbPcXMgjiTqxFAE1FIrK6hl IKsMgjuKWgAoo6VBZ3lvfQedayCSPJXcB3FFwJ6KKKACiiigAooooA534g/8 iRqf+4v/AKGteCV738Qf+RI1P/cX/wBDWvBKAPU/g1/x66r/AL8f8mr0qvNf g1/x66r/AL8f8mr0qgAooooAKiupWhtnkRC7AcADNS1W1BmSzYoxDEgcdTkg YHv6UnsNbjrKONLcOj+YZPmaTu59anpsaLHGqINqqMAU6mhMguLaC7AWVQ23 0JH4cfyqporlY7i1b71vKy8ehOR/OlvxafvAtvFJPjczFR8g9WP9O9QWcX9m JagRu7TIwZVAyXzu/q1Q3qX0Mzx/OyadbRKxAkkJIB6gCtjw0XPh6yMjFmMY OScnHb9K5LxxM8l1bh3Xdhj5avuCDjg+/Wuv0G2e00mGNwFOAdoOQvA//X+N Zwd6rNJK1NGiTgE+leaR3mu6xqM62dzOzZLbVk2gLnH+Feh6jL5Gm3UucbIm b8ga474exZu7uU9kVfzP/wBairrKMQp6Rciv/Zni3+9c/wDf8f40f2Z4t/vX P/f8f4138kiRIXkdUUdSxwKz31/SI2w2oQZ9mz/Kk6UVuwVWT2RgaDYeIY9W he/ef7OuS26YEdOOM12NVLbVNPum2wXkMjf3Q4z+VW61hFRWjuZzk29UFFFN LegzVkDicda5jxFqj3kjaFp0YnuJRiU/woP8f5U/XNYma5Gk6UPMvZeGcdIh /j/KtDQtFh0i12g+ZcPzLKerH/Csm3N8q+ZqkormZyvh+xu9SWa3Or3NvLbN sMQyQB0459QRWx/wjF9/0Hrr9f8AGs7VJDoPjNLwcQXIBcdiDw35da7YMGUM CCCMg1FOEXdPdFTk1ZrZnCeIdPuNItEY6xczSStsWMkjPr3/AM5rQ8Pai+kS JoepxCB+sL/wtnnGfr3qn5v/AAkHjWMD5ra1OR6EKev4mup1jSbfV7QwzDDj lJAOUNKMbtygOUrJRkX6K5fSNWuNMuxo+snDDiG4J4cdgTXUVvGSkjGUXEKK KKokKKKKAOd+IP8AyJGp/wC4v/oa14JXvfxB/wCRI1P/AHF/9DWvBKAPU/g1 /wAeuq/78f8AJq9KrzX4Nf8AHrqv+/H/ACavSqACiiigAqtffKsMh+6kqk/j 8v8AXNWaq6jzZkeroP8Ax4UnsNblqkdQ6FGzgjBwcUtRzzLBHuKsx6BVGST6 UxFG92Q+TawxqqGRWlx/d3Afqf5GprqNbq6it3A2R/vW569QB/PNQMN6PBkS XcrBpNvIjAPc9sD8zVqTA1OE92icfkVqCzhvGSq3iG3to0VVWJFCqMDlj/jX oKLtjVfQAV5/rH+leOkj6/vo1/LFeg1nS+KTLqfDFGX4nk8vw7enPWMr+fFc Lo2uto9jcJBEGuZmGGb7qgD9TXbeKra4u9CmhtYzJISp2jqQDWX4X8MC2C3u oRAz9UibkJ7n3qakZOouUqDioPmMmDQ9d19hcXsrRxnkNMf5L/8AqrTj8CQB f3l9IW/2UAFdfQTirVGPXUh1pdNDhb3wPcRoXs7pZSP4HG0n8araZ4g1LRLo WmoLI8S8NHJ95B6g16Dkt0rI8RaLHqtg21R9qjBMT+/ofY1MqXL70Co1b6TN K2njvLdJ4XDxOMqR3rJ8U28qae+oW95PBLbIcKjfK2T3FYfgXUXiu5NMlJ2s CyA/wsOo/wA+ldJ4o/5Fy9/65/1qubnptk8vJOxymkXd94fg+1S6aJoLgbzc A5bB7E/410lh4r0m8IVpjBIf4ZRgfn0q1oADeH7IMAQYQCDVHVfCWn326SAf ZZjzlB8p+q/4VMYzjFcpTlCT94h8bWiXmirdxEObdt2VORtPB/pWLb+KjF4a NiQ5u1Xy0k7bfX6gVQ1HT9U0Nvs7z4inBT5JPlcdOR/9aunh8FWBsFSSSQ3B XJkB4B+npUe/KTcVZl+7GKUnci8B2Ygsbi/lIXzW2KSf4R/9c/pWnf8AinSb IlfP86QfwxDd+vSuJtLDU9SuX0yKfK27FCrSYVcEgkCut0rwfY2e2S6/0qUc /MMIPw7/AI06bny2ihVFG95MxtTv9Q8S2rLb6Wi20WX86TqAPQ/4ZrX8G2zy 2KajNdTyyODGFZsqqg+n4VuXyKumXKKAqiFgABwODWV4KP8AxTcH+8386tQt NXdyXK8NFY3qKKK3MAooooA534g/8iRqf+4v/oa14JXvfxB/5EjU/wDcX/0N a8EoA9T+DX/Hrqv+/H/Jq9KrzX4Nf8euq/78f8mr0qgAooooAKrajxaZ9HQ/ +PirNV9QgNzYzQgZLLjGcZ9qT2GtynPqTBTcROggVyigjPmkZ3c9gMEZ9all lubq2IWJ7dGTJcsN2MdBjv71BJZpdRg2u3yi/wA8L5G09G6dOD0/GtFkWO0M aDCqm0ZOeMVKu9ynZDbJFjs4VRQo2A4A9qZN/wAhG1/3X/pSWF1by20KRzRs wRflDc9PSluSFvLRie7L/wCO5/pT6C6nD2X+lfEAt1Anc/8AfIP+FehV574O H2jxRJOeflkf8z/9evQJHEcbOc4UEnFZUPhb8zStukOorG0jxHa6vdSwW8Uq 7F3bnAGecdq18FuvArZSUldGTi1owLdhzQFzyacABRTEFFFFAHnjAWfj/CcD 7QP/AB4f/Xrr/Ewz4dvf+uf9a5G0I1Lx6ZE5QTF8+yj/AOsK6vX7LUtQhFrZ zQxW8ikTFwS3sBXND4ZWOifxRuQadq1jpvhyxa6nVCYRhOrH6CsW98V6jqMh g0e1dV6bwu5z/QVBoWm6dHqjafrUDC8B/d73Oxh2x613cEENvGEgiSNR2VcC nHmmt7Clywe1zzq48O6ktnPqWoyiIqu4723Ox7D86dF4w1SKyFuPKZgNolKn cB+eM1s+Pr0pbW9gh+aVt7Aeg6fr/KuRbT5U1MWDkCUsEPoCcf41jP3JWgbQ 9+N5GjZeHr6/sU1GxnSSQsdy7trKwPrWha+I9Z0hxDqtrJJH6yDDfg3Q1L4F uXt7670ybIb7wU9mXhv6flXaSRpKhSRFdT1DDIrSnC8eaLszOpOztJXRkR65 p+qadcC3nAlMTZifhunp3/CofBH/ACLcX++/86xfE1jpn22Oy0u1J1GRuRE2 FUe46VueHdK1LSR9nmuYZbTBYKFIZWPXn0qouTnr0JkoqGnU3aKKK6DAKKKK AOd+IP8AyJGp/wC4v/oa14JXvfxB/wCRI1P/AHF/9DWvBKAPU/g1/wAeuq/7 8f8AJq9KrzX4Nf8AHrqv+/H/ACavSqACiiigAooooAov5o1FzbKh+QeaHJAJ 7dAecZ/SkkuLidZbVbYpLjazhgUXPfPU8dsVLbsFuL0ns4J+mxaWwU/ZVlb7 837xvqe34DA/CpKIZ7eGW7t4fLVvLQ7twz8vQD65A/I1Bdxw2skssCBWitpG kOc8HoP0P5Vdg5vrontsH4Yz/Ws3VJNvhzUbk9ZlYj/d6L+n86l7XGt7HP8A w+j/ANMupP7sYX8z/wDWruGbcMY4PBrkvh9F/ot7J6uq/kM/1rrSGK7cVNFW gi63xs860iU6D4raGf5Y95iYn+6Twf5V6RXKeMNBkvUF/apmeNcSIP419vcV S8PeLRbQrZ6mW2pwk2MkD0b/ABqIP2bcZbFTXtFzLc7iiq9veQXKB4J45VPQ qwP9adJMsSlpJERR3YgV0XMLE1YfirWF0zTmjR/9KmUqgHVR3aqureMLO0Vo 7Mi6n9Rwg/Hv+FY2kaLfa/e/2jqZfyCc5PBk9gOwrGdS/uw3NYU7e9PY0vAm lmG2k1GVcNMNseRzt7n8T/KutpiLsQKoCqBgAdhS4b1rSEeVWM5y5ncztc0a DV7XY37udOY5QOVP+FZ2iazPBdf2PrHyXScRyt0lHbn1/nXRAN3NY3iqxgut HlmljZpYRujaMfMD6fSpkre9EqLv7rMa2hGveNJrhhutrMgD0JXoPzyfwrM1 D/kem/6+U/pWnpWg+ILS1H2a+itxLh2UjJBx34rAuoL1fEphkuFa885R5vQb uMGueV0lddToja7s+h0HiOA6P4itNZiX91I4EuPXv+Y/lWnr2utCyafpg86/ mwF287Ae/wBf/wBdZ97oXiO9t2guNQgljPO08cj8Kt+C9Ojt7F7mWF1vGdkc yDkAdh7VoubmaWlzN8vKm9bF3QNETS4jLK3m3svMsp9+w/zzWxRRXQkoqyMG 23dhRRRTEFFFFAHO/EH/AJEjU/8AcX/0Na8Er3v4g/8AIkan/uL/AOhrXglA Hqfwa/49dV/34/5NXpVea/Br/j11X/fj/k1elUAFFFFABRRRQBQum8uS8x/F b7vxGR/hV2JdkSKOygVWljEt+Ub7pgZT+JFM8yZ9NdBkzx/u329fcj3xyKnY rcjeRm+0mI8zSCFD7gYJ/Dn8qNa06S90WSxtWRCQqjfnGB9Kk/czwRiydN0B DKnTtjBHUcE1NHeRs4jkBhl/uPxn6HofwpWT0Y7taozvC+kzaRp0kFwUMjyl 8ocjGAP6Vs0yaPzYXj3Mm5SNynBHuK42O51mW8Xw8ZpFmjlLPdA/MYuv9f5C k2qaSsNJzbZ2tYer+F9P1JmlCm3nPV4x1+orD1C4uf8AhIby2+16gsUQXats N5HA61o6pfy2Xhq1hhuJftNyQiyT/K6gnJJ9MDioc4yTutilCUWrPcyJPBOp xMfs91A6+uSp/l/WiPwVqkrfv7qFV/3mY/litHTtVnl8M6lC9wWvLMMvmBsk jnBB/Pmsyw1G787Tzaapc3VzK4Etu6kqB35rJxp6aGvNU11N/TPCGnWTLJPm 6kHPzj5R+H+NdCAAMAYFcNf3WoQ6lcvqF3f2iCT908KbogvbNdNrGotZaBLe 2zCVhGCjHkHPQ/rW0JRSdlaxjOMm1d3uadFcXdDVNO0eHWxq8k0jbWeFvuEN 2FQ6lqM0uuyK97e28JhR1SBSxBKg4x+NDq23QKlfZndUVQ0T/kFQnz5p85O+ YYc89xV+tU7q5m1Z2CuRu/Dl/N4nOooYvIMyvy3OBj29q66ilKCluOMnHYKK KKokKKKKACiiigAooooA534g/wDIkan/ALi/+hrXgle9/EH/AJEjU/8AcX/0 Na8EoA9T+DX/AB66r/vx/wAmr0qvNfg1/wAeuq/78f8AJq9KoAKKKKACiiig CvLFMJ/OgZNxXayvnBH17U2GGcXRnk8tcrtITJ3ehOfTn86tUUrDuQz20U+C wIcfddThh+NQS2U00Zjlu2dDwR5a5/PHWrtFFkFw6VhJLow8SPdjUUN2yeT5 e4Y7frxWjq6TyaRdpbZ85omCY65xXKaPc+HY9MtILq2VrxXAZTES+7PX6e1Z zlZpGkI3TZd1C30Y6rcTvrT2twxxIqSbcY7VNHpmkXV3ZJPfNeMsRMUUjAh1 JJ3e/wD9asGeWOPxDqm+4s4sy8faYfMz9OOKuvfWdp4p066kmjW3FkMOi4Xn d0HYZrFSV9V1NHF20fQ0rvS9F0+4lLXQsluoTGYgQFI9QKYttoYhtLmHUlja xxGJ1Yc56BvXv+tZ3ia9tb3UNLuIJ4TCQ43yoWQYI6jvUGoyQP4ck8uaykYX KbjbRbFAwcZGOe9NySbskCi2ldmt/ZekajJP5OrzPCxMksKzZHqTWot7otzb DT1urd4mTyxHv6jpiuVspIf7dJVrafdaOoa0TYqcHlhjms+KNn0uwhktLeCO eXC3pHzDB6Gl7S2yHyX3Z08vh7SbAxNe30v2ZX/dwyyfJn0q+6aZp+tSX016 sU00YXy3YAbeOn5VzviKRtT1drSOC4uILOIp+4Xd+8I6n2/wp08sGo+CnuZo ka9tlELOw+YYI/pVcyTaS2FytpXe51i6tpzRmRb2EoCFLbxjJ6Cpo7u2luHt 450aZOWQHkfh+Ncjrdrb23hmwaCBI2kkiZyoxuOO9VZ4bw+J9TvbBv39oUfZ j76lRkVTqNdCFTT6nbxXtrNE8sdxG0cZIdgwwpHrTLbUbK7cpb3UUrjqFYE1 wELSS+GJpAG+ztqG6cL/AHdorXsruyi8S2senQWLRS5VXiU70XHOfekq17Dd K1zsqKKK6DAKKKKACiiigAooooA534g/8iRqf+4v/oa14JXvfxB/5EjU/wDc X/0Na8EoA9T+DX/Hrqv+/H/Jq9KrzX4Nf8euq/78f8mr0qgAooooAKKKKACi iigAooooAhu5JYbWSSCHzpVXKx5xuPpmucs9au7nVXhXQUFxGwEzB13ID3Jx XU1iaVp9zbeIdUu5UAhnK+Wc5zis5p3VjSLVncr2+s21zZaldSWUCyWjOArE Zk2jPpVebXVePTvK0eGaS6jJVCyjbgnjJFQweFmez1N7q2Bu3d2tz5nqOOnH X1qK40DUTBpSmyScW8TLJG0m0EknjIrG9S39dzVKFzodKzewMbzSobbY2EXK uD69OlZlvr+mm9vbO5tIYEh3EHAIfbntjrWl4et5rW2lilsI7MbsqqSF93HX msu28MC5uLxr+IKGuhLGwIJZecj6GtHzWViFy3dy54f1W11G1u5xZxW0cRw2 McrjPPFR6DrFprLTWjWMcKx4eNCAQwz1xj/Oao/2RqsOnala29uqm7uPlIcA LH/nAqSLQNT03UrC7guFuhFiJ1CiPEf5896lOemnqNqGupdsdZgNvqUi20MD Wzsu0MB5mPwo/tO0Xwy2qyWUSiYbjFgYds4GTjmqEPhfzY9Tku7bM7yM1ud/ rnHQ/wA6a2h6pc2Gl6ewEEUGXlckMN2Tjjv/APXovO2wWhfcvQ6s2o6Gtxb6 UtxJHJse2LD93jvyPTFQ6drtxcie8TRlSNVbzJg45KjODxmpdI0vUdN1e58x xcW9ym5pQAuH/wB2l0nS7y28O3tpLGFmlaQqu4HORxTXO7XB8quVrbxTp66L PcC1jjm34NsP4ye/Tpj+VW4tSsrPw6NZSxiheQcIgAJOcAZxVKDwqP7JWSSE C+S1eMJkYLnO059eaY2h6rcWWl6edsEVuC8khIbD5JHHf/69SnUW66Dah0N/ Q9UXV7AXATy3DFXTOdpFaNc7oml6hpes3RkcT21yN7SgBcP1+7+Jroq2g21r uYzST0CiiirJCiiigAooooA534g/8iRqf+4v/oa14JXvfxB/5EjU/wDcX/0N a8EoA9T+DX/Hrqv+/H/Jq9KrzX4Nf8euq/78f8mr0qgAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigDnfiD/wAiRqf+4v8A6GteCV738Qf+RI1P/cX/ANDWvBKAPU/g1/x66r/v x/yavSq8K8H+MH8LRXSLYrc/aCpyZNu3GfY+tdH/AMLbm/6Aqf8AgQf/AImg D1KivLf+Ftzf9AVP/Ag//E0f8Lbm/wCgKn/gQf8A4mgD1KivLf8Ahbc3/QFT /wACD/8AE0f8Lbm/6Aqf+BB/+JoA9Sory3/hbc3/AEBU/wDAg/8AxNH/AAtu b/oCp/4EH/4mgD1KivLf+Ftzf9AVP/Ag/wDxNH/C25v+gKn/AIEH/wCJoA9S ory3/hbc3/QFT/wIP/xNH/C25v8AoCp/4EH/AOJoA9Sory3/AIW3N/0BU/8A Ag//ABNH/C25v+gKn/gQf/iaAPUqK8t/4W3N/wBAVP8AwIP/AMTR/wALbm/6 Aqf+BB/+JoA9Sory3/hbc3/QFT/wIP8A8TR/wtub/oCp/wCBB/8AiaAPUqK8 t/4W3N/0BU/8CD/8TR/wtub/AKAqf+BB/wDiaAPUqK8t/wCFtzf9AVP/AAIP /wATR/wtub/oCp/4EH/4mgD1KivLf+Ftzf8AQFT/AMCD/wDE0f8AC25v+gKn /gQf/iaAPUqK8t/4W3N/0BU/8CD/APE0f8Lbm/6Aqf8AgQf/AImgD1KivLf+ Ftzf9AVP/Ag//E0f8Lbm/wCgKn/gQf8A4mgD1KivLf8Ahbc3/QFT/wACD/8A E0f8Lbm/6Aqf+BB/+JoA9Sory3/hbc3/AEBU/wDAg/8AxNH/AAtub/oCp/4E H/4mgDsPiD/yJGp/7i/+hrXgld3r/wAR5Na0W501tLWETgDeJt2MEHpt9q4S gD//2Q== ------------=_1557139638-19512-2-- ------=_NextPart_000_009F_01D50427.2451BD70-- From nobody Mon May 6 04:29:44 2019 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 3A98C120077 for ; Mon, 6 May 2019 04:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qdSB0GvNVy5S for ; Mon, 6 May 2019 04:29:40 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5735A120021 for ; Mon, 6 May 2019 04:29:40 -0700 (PDT) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id B205D2D0C; Mon, 6 May 2019 11:29:38 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Alan DeKok In-Reply-To: <009e01d503f9$0a9848f0$1fc8dad0$@cdac.in> Date: Mon, 6 May 2019 07:29:36 -0400 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <77F3AA81-8DF8-4E81-9C03-BA5576A4BB37@deployingradius.com> References: <009e01d503f9$0a9848f0$1fc8dad0$@cdac.in> To: Anoop Kumar Pandey X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Emu] Review of draft draft-ms-emu-eaptlscert-02 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, 06 May 2019 11:29:43 -0000 On May 6, 2019, at 6:47 AM, Anoop Kumar Pandey wrote: > Section 3 talks about various reasons for a certificate being large. = Subject Alternative Name field is typically used for multi-domain or = wildcard certificates (fb.com, *.facebook.om, facebook.net, = messenger.com) where all domains are protected by same certificate. I = doubt that SAN will be a reason in IoT world for larger certificate.=20 EAP-TLS certificates are used in areas other than IoT. > Similarly key size and signature field is in bits (e.g. 2048 bit key, = 2048 bit signature, 224 bit key if ECC is used). So this also = shouldn=E2=80=99t contribute to a larger certificate. >=20 > The same can be said about OID and user groups. Key usage is limited = to digital signature (80) [just one usage] in an end device certificate. = =20 No. Key usage is in every intermediate certificate. i.e. if we have = CA1 - > CA2 - > CA3 -> certs, then all intermediate certs will have OIDs = that allow them to sign subsequent certificates. > Section 4.1.1 talks about shortening or avoid certain fields in the = certificate. Mostly the changes are marginal and the authors have not = presented quantitatively, how much saving in certificate size could be = achieved with it and will it be sufficient. I agree more quantitative numbers would help here. The reality is that there are some organizations who treat = certificates as a dumping ground for information. Every intermediate = cert has names, address, and anything else they can think of. Then, the = CA chain mirrors the corporate reporting chain. The result is a large certificate chain. This happens in the real = world: = http://lists.freeradius.org/pipermail/freeradius-users/2009-February/03562= 1.html ... We are testing WPA2/EAP-TLS authentication, with large certificate chains (just under 64K in PEM format). Some individual cert sizes in the chain approach 10K in DER format. The solution there was "don't use large chains". > Section 4.2.3 talks about compressing the certificate. This is = achievable, however the capability to compress, decompress and = performing ECC certificate validation within a small IoT device is = questionable.=20 Again, this applicability is not just for IoT. > P.S: In EAP-TLS, isn=E2=80=99t there clear direction on how many = packets exchange are allowed before dropping EAP session. Why do some = implementations drop session after 40-50 packets itself?=20 =46rom the above thread, Jouni Malinen (hostap / wpa_supplicant) = responds: = http://lists.freeradius.org/pipermail/freeradius-users/2009-February/03565= 4.html The main (well, more or less, the only) reason for that limit on number of round trips is to work around issues where the EAP peer and server ended up in an infinite loop ACKing their messages. I would prefer to change that to be based on whether any real progress has been made during the last round trip or two, i.e., to remove the hard limit and allow as many round trips as it takes to get through the authentication (or whatever else one adds into EAP, e.g., TNC) 10 years later, the implementation still just counts exchanges. It's = fine, it works. And additional reason to forbid longer exchanges is that it could = potentially be used for bulk data transfer. If the exchange is = unlimited, then a client and home server can collude to "tunnel" generic = IP traffic over EAP. But the biggest reason to limit the exchanges is that there is simply = no reason to allow them. Even in the above situation (64K certificate = chain), there's no *technical* reason for such large chains. > In the standard of EAP-TLS, can the no. of exchange packets be = increased? If yes, apart from latency, what other impact could it have? Realistically, it can't be increased. There are probably tens of = millions of access points and switches in production. They are the = de-facto standard. If you publish a new RFC saying "allow up to 128 = packets", it won't affect those legacy devices. The new standard = *might* start showing up in new devices, once the standard is published. = Or it might not. I've seen standards take 10+ years to *start* getting = adopted. Allowing more packets wouldn't generally increase latency, because = 99.99999999% of authentications won't need more packets. And realistically, if you can't authenticate someone after exchanging = 50K of data, you're likely doing something wrong. Alan DeKok. From nobody Tue May 7 14:56:17 2019 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 1DC68120236; Tue, 7 May 2019 14:56:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, mohit.m.sethi@ericsson.com, emu-chairs@ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155726616204.304.18169745998575739106.idtracker@ietfa.amsl.com> Date: Tue, 07 May 2019 14:56:02 -0700 Archived-At: Subject: [Emu] emu - New Meeting Session Request for IETF 105 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: Tue, 07 May 2019 21:56:03 -0000 A new meeting session request has just been submitted by Mohit Sethi, a Chair of the emu working group. --------------------------------------------------------- Working Group Name: EAP Method Update Area Name: Security Area Session Requester: Mohit Sethi Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: saag tls cfrg lwig Second Priority: curdle uta secdispatch oauth 6lo mls Third Priority: sacm quic kitten bier acme t2trg People who must be present: Eric Rescorla Jari Arkko Joseph A. Salowey Roman Danyliw Alan DeKok John Mattsson Mohit Sethi Resources Requested: Special Requests: If possible, please don't schedule on Monday. --------------------------------------------------------- From nobody Wed May 8 04:17:27 2019 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 B527B12008D for ; Wed, 8 May 2019 04:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcq9gfeKmXuM for ; Wed, 8 May 2019 04:17:23 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB4C12009E for ; Wed, 8 May 2019 04:17:21 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.13.8) with ESMTP id x48BGwdp003027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 May 2019 16:46:58 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id x48BGjt7005894; Wed, 8 May 2019 16:46:47 +0530 X-AuthUser: anoop Received: from DESKTOPV9MK6VP ([223.31.121.170]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id x48BGfxo004455; Wed, 8 May 2019 16:46:42 +0530 From: "Anoop Kumar Pandey" To: "'Alan DeKok'" Cc: References: <009e01d503f9$0a9848f0$1fc8dad0$@cdac.in> <77F3AA81-8DF8-4E81-9C03-BA5576A4BB37@deployingradius.com> In-Reply-To: <77F3AA81-8DF8-4E81-9C03-BA5576A4BB37@deployingradius.com> Date: Wed, 8 May 2019 16:46:40 +0530 Message-ID: <009301d5058f$84c43110$8e4c9330$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0094_01D505BD.9E7D5770" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFRvYB/XICbbSBJFWMOULxvu3QdcAGoSJ1ap1pZeSA= Content-Language: en-in X-CDAC-PUNE-MailScanner-ID: x48BGjt7005894 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.199, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-5.3, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_00 -3.50) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: x48BGwdp003027 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Emu] Review of draft draft-ms-emu-eaptlscert-02 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, 08 May 2019 11:17:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0094_01D505BD.9E7D5770 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > The reality is that there are some organizations who treat certificates a= s a dumping ground for information. 3 Tier chained certificate with organization validated certificate in DER e= ncoded Binary mode has a size of just 1588 byte (1.55 KB) [Attached]. It h= as a lot of Information including SANs and OIDs.=20 You need to show quantitatively with example the effect of the fields that = are responsible for the larger certificate. (Cross certification and certificate transparency could also help in keepin= g the chain small or irrelevant) >> Section 4.2.3 talks about compressing the certificate. This is achievabl= e, however the capability to compress, decompress and performing ECC certif= icate validation within a small IoT device is questionable.=20 >Again, this applicability is not just for IoT. The applicability may not be for IoT but may be for IoT and i= n that case for EAP-TLS to work with certificate compression and ECC, the d= evice should have such capability.=20 >The main (well, more or less, the only) reason for that limit on number of= round trips is to work around issues where the EAP peer and server ended u= p in an infinite loop ACKing their messages. I would prefer to change that = to be based on whether any real progress has been made during the last roun= d trip or two, i.e., to remove the hard limit and allow as many round trips= as it takes to get through the authentication (or whatever else one adds i= nto EAP, e.g., TNC) > 10 years later, the implementation still just counts exchanges. It's fin= e, it works. Agreed >And additional reason to forbid longer exchanges is that it could potentia= lly be used for bulk data transfer. If the exchange is unlimited, then a c= lient and home server can collude to "tunnel" generic IP traffic over EAP. The protocol designer need to take care of such situation. >But the biggest reason to limit the exchanges is that there is simply no r= eason to allow them. Even in the above situation (64K certificate chain), = there's no *technical* reason for such large chains. Practically large chain certificates are there (though I still haven't come= across a 64K certificate), so we can't ignore them. Guidelines can be prov= ided for limiting the information as mentioned in the draft section 4.1.1 >>Realistically, it can't be increased. There are probably tens of millio= ns of access points and switches in production. They are the de-facto stan= dard. If you publish a new RFC saying "allow up to 128 packets", it won't = affect those legacy devices. The new standard *might* start showing up in = new devices, once the standard is published. Or it might not. I've seen s= tandards take 10+ years to *start* getting adopted. This limitation would be with any protocol. If we ask everyone to use ECC o= r certificate caching or certificate compression, that will also take time.= Or if the customer insists or reports, OEM will have to provide firmware u= pgrade or device replacement with new protocol implemented.=20 Regards, Anoop -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: 06 May 2019 05:00 PM To: Anoop Kumar Pandey Cc: emu@ietf.org Subject: Re: [Emu] Review of draft draft-ms-emu-eaptlscert-02 On May 6, 2019, at 6:47 AM, Anoop Kumar Pandey wrote: > Section 3 talks about various reasons for a certificate being large. Subj= ect Alternative Name field is typically used for multi-domain or wildcard c= ertificates (fb.com, *.facebook.om, facebook.net, messenger.com) where all = domains are protected by same certificate. I doubt that SAN will be a reaso= n in IoT world for larger certificate.=20 EAP-TLS certificates are used in areas other than IoT. > Similarly key size and signature field is in bits (e.g. 2048 bit key, 204= 8 bit signature, 224 bit key if ECC is used). So this also shouldn=E2=80=99= t contribute to a larger certificate. >=20 > The same can be said about OID and user groups. Key usage is limited to d= igital signature (80) [just one usage] in an end device certificate.=20=20 No. Key usage is in every intermediate certificate. i.e. if we have CA1= - > CA2 - > CA3 -> certs, then all intermediate certs will have OIDs that = allow them to sign subsequent certificates. > Section 4.1.1 talks about shortening or avoid certain fields in the certi= ficate. Mostly the changes are marginal and the authors have not presented = quantitatively, how much saving in certificate size could be achieved with = it and will it be sufficient. I agree more quantitative numbers would help here. The reality is that there are some organizations who treat certificates a= s a dumping ground for information. Every intermediate cert has names, add= ress, and anything else they can think of. Then, the CA chain mirrors the = corporate reporting chain. The result is a large certificate chain. This happens in the real world: http://lists.freeradius.org/pipermail/freeradius-users/2009-February/035621= .html ... We are testing WPA2/EAP-TLS authentication, with large certificate chains (just under 64K = in PEM format). Some individual cert sizes in the chain approach 10K in DE= R format. The solution there was "don't use large chains". > Section 4.2.3 talks about compressing the certificate. This is achievable= , however the capability to compress, decompress and performing ECC certifi= cate validation within a small IoT device is questionable.=20 Again, this applicability is not just for IoT. > P.S: In EAP-TLS, isn=E2=80=99t there clear direction on how many packets = exchange are allowed before dropping EAP session. Why do some implementatio= ns drop session after 40-50 packets itself?=20 From the above thread, Jouni Malinen (hostap / wpa_supplicant) responds: http://lists.freeradius.org/pipermail/freeradius-users/2009-February/035654= .html The main (well, more or less, the only) reason for that limit on number of = round trips is to work around issues where the EAP peer and server ended up= in an infinite loop ACKing their messages. I would prefer to change that t= o be based on whether any real progress has been made during the last round= trip or two, i.e., to remove the hard limit and allow as many round trips = as it takes to get through the authentication (or whatever else one adds in= to EAP, e.g., TNC) 10 years later, the implementation still just counts exchanges. It's fin= e, it works. And additional reason to forbid longer exchanges is that it could potenti= ally be used for bulk data transfer. If the exchange is unlimited, then a = client and home server can collude to "tunnel" generic IP traffic over EAP. But the biggest reason to limit the exchanges is that there is simply no = reason to allow them. Even in the above situation (64K certificate chain),= there's no *technical* reason for such large chains. > In the standard of EAP-TLS, can the no. of exchange packets be increased?= If yes, apart from latency, what other impact could it have? Realistically, it can't be increased. There are probably tens of million= s of access points and switches in production. They are the de-facto stand= ard. If you publish a new RFC saying "allow up to 128 packets", it won't a= ffect those legacy devices. The new standard *might* start showing up in n= ew devices, once the standard is published. Or it might not. I've seen st= andards take 10+ years to *start* getting adopted. Allowing more packets wouldn't generally increase latency, because 99.999= 99999% of authentications won't need more packets. And realistically, if you can't authenticate someone after exchanging 50K= of data, you're likely doing something wrong. Alan DeKok. ---------------------------------------------------------------------------= --------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ---------------------------------------------------------------------------= --------------------------------- ------=_NextPart_000_0094_01D505BD.9E7D5770 Content-Type: application/x-x509-ca-cert; name="facebook.cer" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="facebook.cer" MIIGMDCCBRigAwIBAgIQC5bdGAoK9GcNIRNiI5SkMjANBgkqhkiG9w0BAQsF ADBwMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEy IEhpZ2ggQXNzdXJhbmNlIFNlcnZlciBDQTAeFw0xOTAzMDgwMDAwMDBaFw0x OTA2MDYxMjAwMDBaMGExCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTETMBEG A1UEBxMKTWVubG8gUGFyazEXMBUGA1UEChMORmFjZWJvb2ssIEluYy4xFzAV BgNVBAMMDiouZmFjZWJvb2suY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcD QgAEUYmYl/ughsSSMESPSvbZ+WMEuccF7tfZDid9xH/jVCpLi5ev+jepkowB /kPmMHUM7jFtIdo9G8pH4+w/UsqQ8KOCA54wggOaMB8GA1UdIwQYMBaAFFFo /5CvAgd1PMzZZWRiohK4WXI7MB0GA1UdDgQWBBROAwZhQ6neuhjMDSYDfYGO oatHqTCBxwYDVR0RBIG/MIG8gg4qLmZhY2Vib29rLmNvbYIGZmIuY29tgg4q Lnh6LmZiY2RuLm5ldIIOKi54eS5mYmNkbi5uZXSCDGZhY2Vib29rLmNvbYIO Ki5mYWNlYm9vay5uZXSCECoubS5mYWNlYm9vay5jb22CCCouZmIuY29tgg4q Lnh4LmZiY2RuLm5ldIIPKi5tZXNzZW5nZXIuY29tggsqLmZiY2RuLm5ldIIN bWVzc2VuZ2VyLmNvbYILKi5mYnNieC5jb20wDgYDVR0PAQH/BAQDAgeAMB0G A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjB1BgNVHR8EbjBsMDSgMqAw hi5odHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc2hhMi1oYS1zZXJ2ZXItZzYu Y3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc2hhMi1oYS1z ZXJ2ZXItZzYuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9bAEBMCowKAYIKwYB BQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQIC MIGDBggrBgEFBQcBAQR3MHUwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRp Z2ljZXJ0LmNvbTBNBggrBgEFBQcwAoZBaHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkhpZ2hBc3N1cmFuY2VTZXJ2ZXJDQS5jcnQw DAYDVR0TAQH/BAIwADCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2ALvZ37wf inG1k5Qjl6qSe0c4V5UKq1LoGpCWZDaOHtGFAAABaVzxBoUAAAQDAEcwRQIg Fz+1EcKmydHQMSNzfBgQQJ2+0a4+Kr3fzDhjMPF9d6sCIQDRpbiMtGJECRAY 66i5KfCYQAupiWYIVBzgERSX1tH7/wB2AId1v+dZfPiMQ5lfvfNu/1aNR1Y2 /0q1YMG06v9eoIMPAAABaVzxB8cAAAQDAEcwRQIhAMMpz3zpdchLbfisbsbt vlBrpIeu2ZvmM2EfLJjqvrWrAiBSDjYmuDWsch7Joe9xN/DXwRH1Taq0C3PL S2p9m9Im9TANBgkqhkiG9w0BAQsFAAOCAQEAHmf0wFs0wLW2boGpnytfqKiD 6zX1B4MJl70UDTd3HwG9+uQsaNgwRBlN3NNmXDgdGNSwhDzORhr4cZfnG+J/ 8DMsfVBousEwP7FTSFdjaAkUW9RbZCJaMKOcs5efUX4p+Up4axiR2/L8cnr9 t3MavjXe4FkKZAbBIU4igKwzjejm4o+rG7dytV7Gug1HO2UO2Cu6CtOC6Ecn OwQb2h2/TTLg3XDHTyfKgpLJkrilMEs98mlrMvCj9KOqoAFAKhmH6Rj9zIfq GJ7ifEb/T83fLQfoQ4auwB7Rmv8HoxjU2rPEqs6POgKKaomeVVnkCJq89tdc oPPlWgwzuQsd/TRiYQ== ------=_NextPart_000_0094_01D505BD.9E7D5770-- From nobody Wed May 8 05:20:55 2019 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 4B7EB120285 for ; Wed, 8 May 2019 05:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kIUYUKCOLfXW for ; Wed, 8 May 2019 05:20:43 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2661C120258 for ; Wed, 8 May 2019 05:20:43 -0700 (PDT) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id DC9E8333; Wed, 8 May 2019 12:20:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Alan DeKok In-Reply-To: <009301d5058f$84c43110$8e4c9330$@cdac.in> Date: Wed, 8 May 2019 08:20:41 -0400 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C8A0582-EAA7-403C-AF0B-956ADE8B6104@deployingradius.com> References: <009e01d503f9$0a9848f0$1fc8dad0$@cdac.in> <77F3AA81-8DF8-4E81-9C03-BA5576A4BB37@deployingradius.com> <009301d5058f$84c43110$8e4c9330$@cdac.in> To: Anoop Kumar Pandey X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Emu] Review of draft draft-ms-emu-eaptlscert-02 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, 08 May 2019 12:20:53 -0000 On May 8, 2019, at 7:16 AM, Anoop Kumar Pandey wrote: >=20 >> The reality is that there are some organizations who treat = certificates as a dumping ground for information. >=20 > 3 Tier chained certificate with organization validated certificate in = DER encoded Binary mode has a size of just 1588 byte (1.55 KB) = [Attached]. It has a lot of Information including SANs and OIDs.=20 >=20 > You need to show quantitatively with example the effect of the fields = that are responsible for the larger certificate. I did. 64K certificate chains contain large certs. Which fields = contribute to that size is less important. If you really care, it's trivial to dump large strings into a = certificate. 1K octet email addresses aren't *technically* forbidden. = Similar arguments go for physical addresses. The point here is that no, I *don't* have to quantitatively = demonstrate which fields are responsible for larger certificates. The = specs don't forbid large values in any field, so therefore the fields = can contain large values. QED. My argument is that we need to explain to administrators *why* such = practices are wrong. Right now, admins who have poor practices discover = that the certificates don't work, for unknown reasons. So to fix it, = people poke at the certs until they work. I'm suggesting that explicit guidance is better than random guesses. >> And additional reason to forbid longer exchanges is that it could = potentially be used for bulk data transfer. If the exchange is = unlimited, then a client and home server can collude to "tunnel" generic = IP traffic over EAP. >=20 > The protocol designer need to take care of such situation. They didn't. Therefore, the implementors chose to enforce a limit. = And that limit is 40-50 packets. We now have to live with that, and bake it into the spec as best = practices for "here's what will work". >>> Realistically, it can't be increased. There are probably tens of = millions of access points and switches in production. They are the = de-facto standard. If you publish a new RFC saying "allow up to 128 = packets", it won't affect those legacy devices. The new standard = *might* start showing up in new devices, once the standard is published. = Or it might not. I've seen standards take 10+ years to *start* getting = adopted. >=20 > This limitation would be with any protocol. If we ask everyone to use = ECC or certificate caching or certificate compression, that will also = take time. These are upgrades to end user devices. > Or if the customer insists or reports, OEM will have to provide = firmware upgrade or device replacement with new protocol implemented.=20 Those are upgrades to WiFi access points and switches. There are tens of millions, if not hundreds of millions of WiFi access = points out there. For many, the vendor is out of business. For others, = the vendor no longer supports that product, maybe due to losing the = source. For others, the admins don't know the passwords to the devices. = For most, admins don't have the time, budget, or inclination to upgrade = our replace them when the devices already work. I'm not sure what the disagreement is here. I'm saying that the = practical limits are ~50 round trips, and maybe ~64K certificate chains. = You're not disagreeing, but you're asking me to justify my position, = and are arguing against it. I'm not clear what point you're trying to = make. Alan DeKok. From nobody Wed May 22 09:42:26 2019 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 3F8DA120108 for ; Wed, 22 May 2019 09:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DKCyS65DTbe9 for ; Wed, 22 May 2019 09:42:22 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id AAF971200B8 for ; Wed, 22 May 2019 09:42:22 -0700 (PDT) Received: from [192.168.20.60] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id 700D71F04 for ; Wed, 22 May 2019 16:42:21 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Wed, 22 May 2019 12:42:37 -0400 To: EMU WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Emu] Can we get a WG last call for draft-dekok-emu-eap-session-id-00 ? 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, 22 May 2019 16:42:25 -0000 Draft is here: https://tools.ietf.org/html/draft-dekok-emu-eap-session-id-00 This is a charter item: https://datatracker.ietf.org/wg/emu/about/ - Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, and EAP-AKA=E2=80=99. The lack of this definition is a recently discovered bug in the original RFCs. There have been minimal comments on the document. What comments have = been received are supportive. Alan DeKok. From nobody Sun May 26 03:08:34 2019 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 A242A120048 for ; Sun, 26 May 2019 03:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 PhgxzJnRQ2BH for ; Sun, 26 May 2019 03:08:30 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50072.outbound.protection.outlook.com [40.107.5.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C88C12015B for ; Sun, 26 May 2019 03:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WSKERbAU4dha2+rhiYkfdzrIfPw65q7sIoYBHBCOKOo=; b=dr48H4dfZj4Gq89yBD9HNrHdiLSpV1RLpsn+j+ps54Ae6yfHIdHZXIshxNlir6v84b4mKRhzb1pyiA+ClozKsD3bErD6uapvKf9jTfl6RF9tb7LsEixtsgVAEjrlE1ywVwr5kFdJTe+sY1i8+m56lq6+HIH/djffSlTGemzAx24= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3082.eurprd07.prod.outlook.com (10.170.244.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.13; Sun, 26 May 2019 10:08:27 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::a2:ab11:d710:4af2]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::a2:ab11:d710:4af2%6]) with mapi id 15.20.1943.007; Sun, 26 May 2019 10:08:27 +0000 From: John Mattsson To: 'EMU WG' Thread-Topic: New Version Notification for draft-ms-emu-eaptlscert-03.txt Thread-Index: AQHVE6oJZfShVJPpHkeLgFQuKDLBy6Z9UByA Date: Sun, 26 May 2019 10:08:26 +0000 Message-ID: References: <155886490186.18477.14054482168171625833.idtracker@ietfa.amsl.com> In-Reply-To: <155886490186.18477.14054482168171625833.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [2a02:8071:82ba:f700:f189:2954:d6a1:9544] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c4877286-e3f0-4c08-a942-08d6e1c218a8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3082; x-ms-traffictypediagnostic: HE1PR07MB3082: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0049B3F387 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(39860400002)(136003)(366004)(199004)(13464003)(189003)(14444005)(256004)(81166006)(8936002)(81156014)(5660300002)(68736007)(36756003)(82746002)(76116006)(229853002)(66946007)(66476007)(64756008)(66446008)(66556008)(91956017)(73956011)(8676002)(6436002)(6486002)(86362001)(6916009)(446003)(6506007)(46003)(53546011)(478600001)(53936002)(476003)(2616005)(11346002)(486006)(44832011)(186003)(2906002)(102836004)(14454004)(966005)(25786009)(33656002)(83716004)(71200400001)(15650500001)(99286004)(76176011)(6116002)(71190400001)(58126008)(305945005)(66574012)(316002)(6306002)(2473003)(6512007)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3082; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ispMyvVwgBZuFTFSv9pn8VIafFBGoJLztJrcVjZaee+NuVFmq+vljBckmwvIomoLVhZxeJlK+LqMxP0Ai9iL7NHyT1uutRL5Tgw7B28jlSSijPoRUfvkbPidPb4FMSGLrFRREmBarSqcsNJk+QjktoySJw+aNSSdvqSeyyWhQxeERtxIgAJYvFtkCJ/Fw+LxulXQKl0oeWsRI5+P5LMVMW63lhIAcuEqTEvfbzgWRTSX0d1UDbcIRWfQXOvAuh4N1WHHCazdqrE3rTDx9m3d8nilN7pwg5+E/mi2gDJOXAsmwtpejwYmxH/+qH4S5jN9OZ0XbSi6CMcYPdajrTof8gjrlDmbp0WyRNxzKccgh6qNBcxd5NBjUco5rgIEqbROhNbENHRlLIPwRQtZTAMX0e0GzPJVm5NwK7F3iqEfXzM= Content-Type: text/plain; charset="utf-8" Content-ID: <4353CF07ED9B334C8B7B248D8BF3FF61@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4877286-e3f0-4c08-a942-08d6e1c218a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2019 10:08:27.2026 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: john.mattsson@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3082 Archived-At: Subject: [Emu] FW: New Version Notification for draft-ms-emu-eaptlscert-03.txt 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: Sun, 26 May 2019 10:08:33 -0000 SGksDQoNClRoZSBjaGFuZ2VzIGluIC0wMyBhcmU6DQoNCi0gQWRkZWQgdGV4dCB0byB0aGUgIlVw ZGF0ZSBBdXRoZW50aWNhdG9yIiBzZWN0aW9uIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyBvbiB0 aGUgbWFpbGluZyBsaXN0Lg0KLSBBZGRlZCB0ZXh0IGRlc2NyaWJpbmcgdGhlIFN1cHByZXNzaW5n IEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZXMgZHJhZnQgZHJhZnQtdGhvbXNvbi10bHMtc2ljDQot IEFkZGVkIHJlZmVyZW5jZXMgdG8gb3RoZXIgVExTLWJhc2VkIEVBUCBtZXRob2RzLg0KDQpDaGVl cnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KRGF0ZTogU3Vu ZGF5LCAyNiBNYXkgMjAxOSBhdCAxMjowMQ0KVG86IE1vaGl0IFNldGhpIDxtb2hpdEBwaXVoYS5u ZXQ+LCBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4sIFNlYW4gVHVy bmVyIDxzZWFuQHNuM3JkLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtbXMtZW11LWVhcHRsc2NlcnQtMDMudHh0DQoNCiAgICANCiAgICBBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtbXMtZW11LWVhcHRsc2NlcnQtMDMudHh0DQogICAgaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIE1hdHRzc29uIGFuZCBwb3N0ZWQgdG8gdGhl DQogICAgSUVURiByZXBvc2l0b3J5Lg0KICAgIA0KICAgIE5hbWU6CQlkcmFmdC1tcy1lbXUtZWFw dGxzY2VydA0KICAgIFJldmlzaW9uOgkwMw0KICAgIFRpdGxlOgkJSGFuZGxpbmcgTGFyZ2UgQ2Vy dGlmaWNhdGVzIGFuZCBMb25nIENlcnRpZmljYXRlIENoYWlucyBpbiBUTFMtYmFzZWQgRUFQIE1l dGhvZHMNCiAgICBEb2N1bWVudCBkYXRlOgkyMDE5LTA1LTI2DQogICAgR3JvdXA6CQlJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCiAgICBQYWdlczoJCTEwDQogICAgVVJMOiAgICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tcy1lbXUtZWFwdGxzY2VydC0w My50eHQNCiAgICBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbXMtZW11LWVhcHRsc2NlcnQvDQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tcy1lbXUtZWFwdGxzY2VydC0wMw0KICAgIEh0bWxp emVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1z LWVtdS1lYXB0bHNjZXJ0DQogICAgRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1tcy1lbXUtZWFwdGxzY2VydC0wMw0KICAgIA0KICAgIEFic3Ry YWN0Og0KICAgICAgIEVBUC1UTFMgYW5kIG90aGVyIFRMUy1iYXNlZCBFQVAgbWV0aG9kcyBhcmUg d2lkZWx5IGRlcGxveWVkIGFuZCB1c2VkDQogICAgICAgZm9yIG5ldHdvcmsgYWNjZXNzIGF1dGhl bnRpY2F0aW9uLiAgTGFyZ2UgY2VydGlmaWNhdGVzIGFuZCBsb25nDQogICAgICAgY2VydGlmaWNh dGUgY2hhaW5zIGNvbWJpbmVkIHdpdGggYXV0aGVudGljYXRvcnMgdGhhdCBkcm9wIGFuIEVBUA0K ICAgICAgIHNlc3Npb24gYWZ0ZXIgb25seSA0MCAtIDUwIHJvdW5kLXRyaXBzIGlzIGEgbWFqb3Ig ZGVwbG95bWVudCBwcm9ibGVtLg0KICAgICAgIFRoaXMgbWVtbyBsb29rcyBhdCB0aGUgdGhpcyBw cm9ibGVtIGluIGRldGFpbCBhbmQgZGVzY3JpYmVzIHRoZQ0KICAgICAgIHBvdGVudGlhbCBzb2x1 dGlvbnMgYXZhaWxhYmxlLg0KICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICAN CiAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAgIA0KICAgIA0KDQo= From nobody Sun May 26 04:28:53 2019 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 5D808120113; Sun, 26 May 2019 04:28:52 -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: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <155887013233.18517.2148552562787933609@ietfa.amsl.com> Date: Sun, 26 May 2019 04:28:52 -0700 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-05.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: Sun, 26 May 2019 11:28:52 -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 Authors : John Mattsson Mohit Sethi Filename : draft-ietf-emu-eap-tls13-05.txt Pages : 26 Date : 2019-05-26 Abstract: This document specifies the use of 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 further improves security and privacy by mandating use of privacy and revocation checking. 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-05 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 26 04:49:05 2019 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 3719312015F for ; Sun, 26 May 2019 04:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 f8_ldezFySxX for ; Sun, 26 May 2019 04:49:00 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00062.outbound.protection.outlook.com [40.107.0.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A4212001E for ; Sun, 26 May 2019 04:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NGuPjOLoMltSua/1sMfCB4mWqNiGqU8YwY9c0hjKB+c=; b=N4tyeTv6VrPsnBHjZfXp7BNvZyRbuRE5131FDcfqXMVABt4Djp8hIiZIIjQwM0Nw3qXuX8eZEI2EViQsoZYiH88uCUN3vhvPEwIO9lD6qm0CYocwxNyYBKvDvKTXqgQ1hMdcvAvYRz7j7FAxBIv+8mRt2NdRnvci71roalro0b0= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3258.eurprd07.prod.outlook.com (10.170.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.10; Sun, 26 May 2019 11:48:57 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::a2:ab11:d710:4af2]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::a2:ab11:d710:4af2%6]) with mapi id 15.20.1943.007; Sun, 26 May 2019 11:48:57 +0000 From: John Mattsson To: "emu@ietf.org" Thread-Topic: [Emu] I-D Action: draft-ietf-emu-eap-tls13-05.txt Thread-Index: AQHVE7Y6qw+Ju0oPOkGpG5u4k0H8gqZ9bBkA Date: Sun, 26 May 2019 11:48:57 +0000 Message-ID: <8195EFFD-6846-48C7-9641-1351E5D3A76A@ericsson.com> References: <155887013233.18517.2148552562787933609@ietfa.amsl.com> In-Reply-To: <155887013233.18517.2148552562787933609@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [2a02:8071:82ba:f700:f189:2954:d6a1:9544] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3388bcc9-d6ae-422b-5487-08d6e1d022bc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3258; x-ms-traffictypediagnostic: HE1PR07MB3258: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0049B3F387 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(346002)(39860400002)(396003)(376002)(189003)(199004)(13464003)(66446008)(66556008)(66946007)(64756008)(66476007)(73956011)(46003)(305945005)(91956017)(7736002)(76116006)(68736007)(486006)(66574012)(186003)(1730700003)(81166006)(8676002)(8936002)(6506007)(53546011)(102836004)(33656002)(81156014)(76176011)(6916009)(58126008)(2501003)(36756003)(99286004)(2473003)(6512007)(53936002)(6306002)(14444005)(6486002)(476003)(2351001)(2616005)(256004)(5660300002)(44832011)(86362001)(966005)(6436002)(478600001)(229853002)(446003)(5640700003)(82746002)(2906002)(83716004)(25786009)(71200400001)(71190400001)(316002)(6116002)(14454004)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3258; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wn7LN2B0Iwwb5J9Ut/l/nvwy4kd52bH0mKG17JVpIdwe7QYx4s81TNfThPqLNWBABpYFye56vD0MJX3YAqQQLlosnLWhgxqfFYe/P+L5c6YIsyKoybi3QFCZq/kfyiQ0XuB4goSIJAU/mr0Y5QNOV3/irI+7HyGbY8Rb+NJX4L7So1XzDiPbrHrgapxfQBCt9sqVuPOUEyvpgRwr0QHQ739BeiZCvYnp/zGO/x5uMkyXxIR7R1dOFasUuIXjuy+CymBAXfJ1QThDDaV2S1YES//M2DTAPUqJ9J0YakhOgjifgbpNxLuiwKJyxzwyizxubtdYt2EAmltnJrIdbXxgY4K9OD2X0hjn3Z2qkpZ9OIeE4wxR+dddd/9zvRKk2aXhqfuGWuyJH9wkqOlrsOfi7FEK6JpxAiRG0mj5xL/RhUk= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3388bcc9-d6ae-422b-5487-08d6e1d022bc X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2019 11:48:57.0499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: john.mattsson@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3258 Archived-At: Subject: [Emu] FW: I-D Action: draft-ietf-emu-eap-tls13-05.txt 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: Sun, 26 May 2019 11:49:03 -0000 SGksDQoNClRoZSBjaGFuZ2VzIGluIHRoZSAwNSB2ZXJzaW9uIGFyZToNCg0KLSBBZGRlZCBuZXcg c3Vic2VjdGlvbiBmb3IgSGVsbG8gUmV0cnkgUmVxdWVzdA0KLSBDaGFuZ2VkIHRoZSBvcmRlciBv ZiBzb21lIHN1YnN1YnNlY3Rpb24gaW4gc2VjdGlvbiAyLjENCi0gUmVtb3ZlZCBhbGwgdGV4dCBv biBvdGhlciBUTFMtYmFzZWQgRUFQIG1ldGhvZHMgYXMgYWdyZWVkIGF0IElFVEYgMTA0DQotIEFk ZGVkIGEgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZSAo d2hpY2ggdXBkYXRlcyBSRkMgNTIxNikgYW5kIG1hZGUgY2hhbmdlcyBiYXNlZCBvbiB0aGlzLg0K LSBBZGRlZCBjbGFyaWZpY2F0aW9uIG9uIGhvdyB0byB0cmVhdCB0aGUgZnJhZ21lbnRhdGlvbiBM IGJpdC4NCi0gU2V2ZXJhbCBjaGFuZ2VzICgiZWFybHlfZGF0YSIsIGVtcHR5IGNlcnRpZmljYXRl X2xpc3QsIG90aGVyIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24sIGZvcmNlIGEgZnVsbCBUTFMg aGFuZHNoYWtlKSBiYXNlZCBvbiB0aGUgcmV2aWV3IGJ5IEppbSBTY2hhYWQuDQoNCkNoZWVycywN CkpvaG4NCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVtdSA8ZW11LWJv dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KUmVwbHktVG86ICJlbXVAaWV0Zi5vcmciIDxlbXVA aWV0Zi5vcmc+DQpEYXRlOiBTdW5kYXksIDI2IE1heSAyMDE5IGF0IDEzOjI5DQpUbzogImktZC1h bm5vdW5jZUBpZXRmLm9yZyIgPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiAiZW11QGlldGYu b3JnIiA8ZW11QGlldGYub3JnPg0KU3ViamVjdDogW0VtdV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1lbXUtZWFwLXRsczEzLTA1LnR4dA0KDQogICAgDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz Lg0KICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEVBUCBNZXRob2QgVXBkYXRl IFdHIG9mIHRoZSBJRVRGLg0KICAgIA0KICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogVXNp bmcgRUFQLVRMUyB3aXRoIFRMUyAxLjMNCiAgICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IEpv aG4gTWF0dHNzb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1vaGl0IFNldGhpDQog ICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtZW11LWVhcC10bHMxMy0wNS50eHQNCiAg ICAJUGFnZXMgICAgICAgICAgIDogMjYNCiAgICAJRGF0ZSAgICAgICAgICAgIDogMjAxOS0wNS0y Ng0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRo ZSB1c2Ugb2YgRUFQLVRMUyB3aXRoIFRMUyAxLjMgd2hpbGUNCiAgICAgICByZW1haW5pbmcgYmFj a3dhcmRzIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgRUFQLQ0K ICAgICAgIFRMUy4gIFRMUyAxLjMgcHJvdmlkZXMgc2lnbmlmaWNhbnRseSBpbXByb3ZlZCBzZWN1 cml0eSwgcHJpdmFjeSwgYW5kDQogICAgICAgcmVkdWNlZCBsYXRlbmN5IHdoZW4gY29tcGFyZWQg dG8gZWFybGllciB2ZXJzaW9ucyBvZiBUTFMuICBFQVAtVExTDQogICAgICAgd2l0aCBUTFMgMS4z IGZ1cnRoZXIgaW1wcm92ZXMgc2VjdXJpdHkgYW5kIHByaXZhY3kgYnkgbWFuZGF0aW5nIHVzZQ0K ICAgICAgIG9mIHByaXZhY3kgYW5kIHJldm9jYXRpb24gY2hlY2tpbmcuICBUaGlzIGRvY3VtZW50 IHVwZGF0ZXMgUkZDIDUyMTYuDQogICAgDQogICAgDQogICAgVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzLw0KICAgIA0KICAgIFRoZXJlIGFy ZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzLTA1DQogICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMtMDUN CiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZW11 LWVhcC10bHMxMy0wNQ0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KICAgIA0KICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQogICAgRW11IG1haWxpbmcgbGlzdA0KICAgIEVtdUBpZXRmLm9yZw0KICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW11DQogICAgDQoNCg==